request sense

request sense

[Matthew Wilcox]

Found a funny in the sym2 driver I'm not sure how to resolve:

                cp->sensecmd[0]         = REQUEST_SENSE;
                cp->sensecmd[1]         = 0;
                if (tp->tinfo.curr.scsi_version <= 2 && cp->lun <= 7)
                        cp->sensecmd[1] = cp->lun << 5;

Thing is, we don't set scsi_version anywhere, so I'm sure sym2 currently
does The Wrong Thing for SCSI-2 drives.  Pulling up the (draft) specs,
this does seem to be something that changed between SCSI-2 and SPC3r15.
Polling some of the other scsi drivers for a solution:

3w-9xxx		Never fills in LUN
53c700		Always fills in LUN
BusLogic	Doesn't send REQUEST_SENSE
aic7xxx		Same as sym2 (except it sets its equivalent of scsi_version)
dc395x		Always fills in LUN
gdth		Doesn't send REQUEST_SENSE
ipr		Never fills in LUN
ips		Doesn't send REQUEST_SENSE
ncr53c8xx	Doesn't send REQUEST_SENSE
qla1280		Doesn't send REQUEST_SENSE
sym53c416	Doesn't send REQUEST_SENSE
tmscsim		Always fills in LUN

In other words, the only driver I've found that gets this *right* is
aic7xxx (and 79xx).  Even scsi_error.c doesn't fill in the LUN.  What's
going on here?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: request sense

[Douglas Gilbert]

Matthew Wilcox wrote:
> Found a funny in the sym2 driver I'm not sure how to resolve:
> 
>                 cp->sensecmd[0]         = REQUEST_SENSE;
>                 cp->sensecmd[1]         = 0;
>                 if (tp->tinfo.curr.scsi_version <= 2 && cp->lun <= 7)
>                         cp->sensecmd[1] = cp->lun << 5;
> 
> Thing is, we don't set scsi_version anywhere, so I'm sure sym2 currently
> does The Wrong Thing for SCSI-2 drives.  Pulling up the (draft) specs,
> this does seem to be something that changed between SCSI-2 and SPC3r15.
> Polling some of the other scsi drivers for a solution:
> 
> 3w-9xxx		Never fills in LUN
> 53c700		Always fills in LUN
> BusLogic	Doesn't send REQUEST_SENSE
> aic7xxx		Same as sym2 (except it sets its equivalent of scsi_version)
> dc395x		Always fills in LUN
> gdth		Doesn't send REQUEST_SENSE
> ipr		Never fills in LUN
> ips		Doesn't send REQUEST_SENSE
> ncr53c8xx	Doesn't send REQUEST_SENSE
> qla1280		Doesn't send REQUEST_SENSE
> sym53c416	Doesn't send REQUEST_SENSE
> tmscsim		Always fills in LUN
> 
> In other words, the only driver I've found that gets this *right* is
> aic7xxx (and 79xx).  Even scsi_error.c doesn't fill in the LUN.  What's
> going on here?

Matthew,
Back in SCSI-2 (final t10 draft in 1993, standard in 1994) all
SCSI commands (I believe) used the top 3 bits of byte 1 of a cdb
for the logical unit number (lun). In those days SCSI had only
one transport (now called SPI) and luns were limited to 8 (3 bits)
for each target.

By SPC (part of the original "SCSI-3") those 3 bits were reserved
and luns had increased to 32 bits and were conveyed across the
SCSI transport by soem other mechanism (i.e. not the cdb). SPC was
standardized in 1997 and the final draft is dated almost 8 years
ago.

Now SPC-3 is in the process of being voted on. Those top 3 bits
in byte 1 of each cdb are now being re-used by some commands.
For example, there is now something called "protection information"
which adds an extra 8 bytes to each block. If a disk supports it
(PROTECT bit set in an INQUIRY response), then an application
can format a disk with it by setting byte 1, bit 7 of the
FORMAT UNIT cdb. 11 years ago that bit would have been part of
the lun number. Even READ and WRITE cdbs now use the former lun
bits.

So unless a LLD knows that it is using such an old version
of SPI that it has no other mechanism for conveying a lun
_and_ the mid level structure indicates a lun > 0 (and
lun < 8) then it should not overwrite those bits, IMO.

The LLD obviously knows the version of SPI that a target
supports and the "version" field in an INQUIRY response
indicates which SCSI command set generation the device claims
to support (SPC-3 rev 21d, table 81 on page 145). As has been
discussed elsewhere, one should not necessary believe the
value a device puts in the version field (especially if
an LLD hacks it).

As for REQUEST SENSE, that was used before the days of auto
sense to retrieve the sense data when a CHECK CONDITION status
was reported by a command. Now auto sense is mandatory and
REQUEST SENSE almost fell out of use. Prior to auto-sense,
the mid level (or perhaps the LLD) build REQUEST SENSE cdbs
and in SCSI-2 then had to worry about the lun. The good
news is that the top 3 bits of byte 1 of the REQUEST SENSE
cdb are still reserved. Only an extremely pedantic SCSI
command interpreter would complain if they were set (IMO).

Aside: REQUEST SENSE has now made a comeback. It is used
to report the power condition of a device. It is also used
to convey a progress indication for long duration commands
like FORMAT UNIT that are executed with the IMMED bit set
(i.e. start the command then return a GOOD status). This
progress indication role used to be performed by TEST UNIT
READY (and still is in disks that I have tested).


Basically it's a moving target, albeit a very slow one :-)

Doug Gilbert

Re: request sense

[Matthew Wilcox]

On Fri, Feb 25, 2005 at 02:02:20PM +1000, Douglas Gilbert wrote:
> Matthew Wilcox wrote:
> >3w-9xxx	Never fills in LUN
> >53c700	Always fills in LUN
> >BusLogic	Doesn't send REQUEST_SENSE
> >aic7xxx	Same as sym2 (except it sets its equivalent of scsi_version)
> >dc395x	Always fills in LUN
> >gdth		Doesn't send REQUEST_SENSE
> >ipr		Never fills in LUN
> >ips		Doesn't send REQUEST_SENSE
> >ncr53c8xx	Doesn't send REQUEST_SENSE
> >qla1280	Doesn't send REQUEST_SENSE
> >sym53c416	Doesn't send REQUEST_SENSE
> >tmscsim	Always fills in LUN
> 
> Matthew,
> Back in SCSI-2 (final t10 draft in 1993, standard in 1994) all
> SCSI commands (I believe) used the top 3 bits of byte 1 of a cdb
> for the logical unit number (lun). In those days SCSI had only
> one transport (now called SPI) and luns were limited to 8 (3 bits)
> for each target.
> 
> By SPC (part of the original "SCSI-3") those 3 bits were reserved
> and luns had increased to 32 bits and were conveyed across the
> SCSI transport by soem other mechanism (i.e. not the cdb). SPC was
> standardized in 1997 and the final draft is dated almost 8 years
> ago.

Thanks for the extremely clear explanation.  I suppose the effect of this
bug is pretty minimal -- it only affects multi-lun scsi-2 devices, and even
with those, it simply gets the sense data from the wrong LUN.  

> So unless a LLD knows that it is using such an old version
> of SPI that it has no other mechanism for conveying a lun
> _and_ the mid level structure indicates a lun > 0 (and
> lun < 8) then it should not overwrite those bits, IMO.
> 
> The LLD obviously knows the version of SPI that a target
> supports and the "version" field in an INQUIRY response
> indicates which SCSI command set generation the device claims
> to support (SPC-3 rev 21d, table 81 on page 145). As has been
> discussed elsewhere, one should not necessary believe the
> value a device puts in the version field (especially if
> an LLD hacks it).
> 
> As for REQUEST SENSE, that was used before the days of auto
> sense to retrieve the sense data when a CHECK CONDITION status
> was reported by a command. Now auto sense is mandatory and
> REQUEST SENSE almost fell out of use. Prior to auto-sense,
> the mid level (or perhaps the LLD) build REQUEST SENSE cdbs
> and in SCSI-2 then had to worry about the lun. The good
> news is that the top 3 bits of byte 1 of the REQUEST SENSE
> cdb are still reserved. Only an extremely pedantic SCSI
> command interpreter would complain if they were set (IMO).

That argues in favour of having scsi_error's implementation set the lun
bits, conditional on sdev->scsi_level, right?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: request sense

[Patrick Mansfield]

On Fri, Feb 25, 2005 at 03:37:50PM +0000, Matthew Wilcox wrote:
> On Fri, Feb 25, 2005 at 02:02:20PM +1000, Douglas Gilbert wrote:

> > Back in SCSI-2 (final t10 draft in 1993, standard in 1994) all
> > SCSI commands (I believe) used the top 3 bits of byte 1 of a cdb
> > for the logical unit number (lun). In those days SCSI had only
> > one transport (now called SPI) and luns were limited to 8 (3 bits)
> > for each target.
> > 
> > By SPC (part of the original "SCSI-3") those 3 bits were reserved
> > and luns had increased to 32 bits and were conveyed across the
> > SCSI transport by soem other mechanism (i.e. not the cdb). SPC was
> > standardized in 1997 and the final draft is dated almost 8 years
> > ago.
> 
> Thanks for the extremely clear explanation.  I suppose the effect of this
> bug is pretty minimal -- it only affects multi-lun scsi-2 devices, and even
> with those, it simply gets the sense data from the wrong LUN.  

I assume you mean _potentially_ affects affects only multi-lun scsi-2
earlier devices?

> That argues in favour of having scsi_error's implementation set the lun
> bits, conditional on sdev->scsi_level, right?

It already does so for all commands, see scsi_send_eh_cmnd():

	if (scmd->device->scsi_level <= SCSI_2)
		scmd->cmnd[1] = (scmd->cmnd[1] & 0x1f) |
		(scmd->device->lun << 5 & 0xe0);

And scsi_dispatch_cmd() has the same code for the normal IO paths.

-- Patrick Mansfield