SAI_READ_CAPACITY_16?

SAI_READ_CAPACITY_16?

[Salyzyn, Mark]

Troubled spoofing back >2TB support in the aacraid driver.

For some reason, sd_read_capacity (in sd.c) in the 2.6.9-5.EL (RHEL4)
kernel is not issuing the SERVICE_REQUEST_IN+SAI_READ_CAPACITY_16
command to the queuecommand handler (the handler is not even called),
even though it instruments up that the command is issued (and returns
not supported). The READ_CAPACITY call makes it through successfully
indicating 0xFFFFFFFF capacity to trigger the SAI_READ_CAPACITY_16
request fine. Could there be a bug in the scsi layers reissuing commands
reusing the request structure misdirecting the requests?

The only changes to the current tree appear to be in the handling of the
request sense information, so I expect the same behavior from
latest/greatest.

Any successes in the current tree with >2TB support being reported by
the SAI_READ_CAPACITY_16 call?

Sincerely -- Mark Salyzyn

Re: SAI_READ_CAPACITY_16?

[Ming Zhang]

we tested several iSCSI initiator/target combinations that work with
>2TB devices in current 2.6.11.x kernel.

our experience is that some code only support cdb len 10 or 12. you need
16.

Ming


On Wed, 2005-04-06 at 12:00, Salyzyn, Mark wrote:
> Troubled spoofing back >2TB support in the aacraid driver.
> 
> For some reason, sd_read_capacity (in sd.c) in the 2.6.9-5.EL (RHEL4)
> kernel is not issuing the SERVICE_REQUEST_IN+SAI_READ_CAPACITY_16
> command to the queuecommand handler (the handler is not even called),
> even though it instruments up that the command is issued (and returns
> not supported). The READ_CAPACITY call makes it through successfully
> indicating 0xFFFFFFFF capacity to trigger the SAI_READ_CAPACITY_16
> request fine. Could there be a bug in the scsi layers reissuing commands
> reusing the request structure misdirecting the requests?
> 
> The only changes to the current tree appear to be in the handling of the
> request sense information, so I expect the same behavior from
> latest/greatest.
> 
> Any successes in the current tree with >2TB support being reported by
> the SAI_READ_CAPACITY_16 call?
> 
> Sincerely -- Mark Salyzyn
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SAI_READ_CAPACITY_16?

[James Bottomley]

On Wed, 2005-04-06 at 12:00 -0400, Salyzyn, Mark wrote:
> For some reason, sd_read_capacity (in sd.c) in the 2.6.9-5.EL (RHEL4)
> kernel is not issuing the SERVICE_REQUEST_IN+SAI_READ_CAPACITY_16
> command to the queuecommand handler (the handler is not even called),
> even though it instruments up that the command is issued (and returns
> not supported). The READ_CAPACITY call makes it through successfully
> indicating 0xFFFFFFFF capacity to trigger the SAI_READ_CAPACITY_16
> request fine. Could there be a bug in the scsi layers reissuing commands
> reusing the request structure misdirecting the requests?

The person who coded it gave a success report on it ... and I've had
several others since then.

On a 32 bit system, you have to have CONFIG_LBD for it to work.

This code is pretty verbose, what are your kernel traces?

James

RE: SAI_READ_CAPACITY_16?

[Salyzyn, Mark]

Thanks, needed to set shost->max_cmd_len to 16 in the driver.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: Ming Zhang [mailto:mingz@ele.uri.edu] 
Sent: Wednesday, April 06, 2005 12:12 PM
To: Salyzyn, Mark
Cc: Linux SCSI
Subject: Re: SAI_READ_CAPACITY_16?

we tested several iSCSI initiator/target combinations that work with
>2TB devices in current 2.6.11.x kernel.

our experience is that some code only support cdb len 10 or 12. you need
16.

Ming


On Wed, 2005-04-06 at 12:00, Salyzyn, Mark wrote:
> Troubled spoofing back >2TB support in the aacraid driver.
> 
> For some reason, sd_read_capacity (in sd.c) in the 2.6.9-5.EL (RHEL4)
> kernel is not issuing the SERVICE_REQUEST_IN+SAI_READ_CAPACITY_16
> command to the queuecommand handler (the handler is not even called),
> even though it instruments up that the command is issued (and returns
> not supported). The READ_CAPACITY call makes it through successfully
> indicating 0xFFFFFFFF capacity to trigger the SAI_READ_CAPACITY_16
> request fine. Could there be a bug in the scsi layers reissuing
commands
> reusing the request structure misdirecting the requests?
> 
> The only changes to the current tree appear to be in the handling of
the
> request sense information, so I expect the same behavior from
> latest/greatest.
> 
> Any successes in the current tree with >2TB support being reported by
> the SAI_READ_CAPACITY_16 call?
> 
> Sincerely -- Mark Salyzyn
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: SAI_READ_CAPACITY_16?

[Ming Zhang]

welcome. let us know if works. thx.

ming

On Wed, 2005-04-06 at 14:30, Salyzyn, Mark wrote:
> Thanks, needed to set shost->max_cmd_len to 16 in the driver.
> 
> Sincerely -- Mark Salyzyn
> 
> -----Original Message-----
> From: Ming Zhang [mailto:mingz@ele.uri.edu] 
> Sent: Wednesday, April 06, 2005 12:12 PM
> To: Salyzyn, Mark
> Cc: Linux SCSI
> Subject: Re: SAI_READ_CAPACITY_16?
> 
> we tested several iSCSI initiator/target combinations that work with
> >2TB devices in current 2.6.11.x kernel.
> 
> our experience is that some code only support cdb len 10 or 12. you need
> 16.
> 
> Ming
> 
> 
> On Wed, 2005-04-06 at 12:00, Salyzyn, Mark wrote:
> > Troubled spoofing back >2TB support in the aacraid driver.
> > 
> > For some reason, sd_read_capacity (in sd.c) in the 2.6.9-5.EL (RHEL4)
> > kernel is not issuing the SERVICE_REQUEST_IN+SAI_READ_CAPACITY_16
> > command to the queuecommand handler (the handler is not even called),
> > even though it instruments up that the command is issued (and returns
> > not supported). The READ_CAPACITY call makes it through successfully
> > indicating 0xFFFFFFFF capacity to trigger the SAI_READ_CAPACITY_16
> > request fine. Could there be a bug in the scsi layers reissuing
> commands
> > reusing the request structure misdirecting the requests?
> > 
> > The only changes to the current tree appear to be in the handling of
> the
> > request sense information, so I expect the same behavior from
> > latest/greatest.
> > 
> > Any successes in the current tree with >2TB support being reported by
> > the SAI_READ_CAPACITY_16 call?
> > 
> > Sincerely -- Mark Salyzyn
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>