RE: Re: inquiry in scsi_scan.c

RE: Re: inquiry in scsi_scan.c

[Cress, Andrew R]

I think SCSI-Core should care about offsets 36-48, since that is where the
serial number usually is returned.  Special error handling for emulated
devices would be better than limiting the inquiry up front I think.

Andy

-----Original Message-----
From: Matthew Dharm [mailto:mdharm-scsi@one-eyed-alien.net] 
Sent: Monday, January 06, 2003 4:06 PM
To: Luben Tuikov
Cc: Andries.Brouwer@cwi.nl; stern@rowland.harvard.edu;
linux-scsi@vger.kernel.org; linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] Re: inquiry in scsi_scan.c


I'm told this is a bad idea because there are some HBA which snoop the
INQUIRY data.  Since I don't know how that snooping works, I can't comment
further.

Matt

On Mon, Jan 06, 2003 at 03:49:08PM -0500, Luben Tuikov wrote:
> Matthew Dharm wrote:
> > 
> > Perhaps the "best" fix here is to simply make scsi_scan.c only send 36
byte
> > inquiry requests if the bus is 'emulated'.  That would solve a world of
> > problems....
> 
> When scsi_scan.c does it's own scanning for SCSI Core, maybe it's best to
> ignore 36 < INQUIRY_DATA_LEN < 57, since this is just vendor specific
> data and SCSI Core is not interested in it.
> 
> In descriptive-C this looks like this:
> 
> </issue a 36 byte buffer INQUIRY/>
> </now dissect:/>
> 
> int bytes_got = max(bytes_requested - cmd->resid, 0);
> 
> if (31 < buffer[4] && buffer[4] < 52) {
> 	/* we don't care, do not issue another INQUIRY */	
> else if (buffer[4] >= 52) {
> 	bytes_requested = 5+buffer[4];
> 	/* issue another INQUIRY to get the additional flags, */
> 	/* plus any version descriptors if available */
> 	</insert code here/>
> 	bytes_got = max(bytes_requested - cmd->resid, 0);
> }
> 
> if (bytes_got != buffer[4]+5) {
> 	/* let's rely on the transport to have correctly set */
> 	/* cmd->resid and report a broken device server */
> 	</insert code here/>
> }
> 
> /* Now we rely on bytes_got */
> 
> </rest of scanning code/>
> 
> -- 
> Luben
> 

-- 
Matthew Dharm                              Home:
mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

Would you mind not using our Web server? We're trying to have a game of 
Quake here.
					-- Greg
User Friendly, 5/11/1998


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Re: inquiry in scsi_scan.c

[Luben Tuikov]

Cress, Andrew R wrote:
> I think SCSI-Core should care about offsets 36-48, since that is where the
> serial number usually is returned.  Special error handling for emulated
> devices would be better than limiting the inquiry up front I think.

We were discussing the case when CmdDt = 0 and EVPD = 0.
This is the ``Standard INQUIRY data format'' table SPC-3.

-- 
Luben




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Re: inquiry in scsi_scan.c

[Andries.Brouwer]

> US_FL_DONT_FIX_INQUIRY_LENGTH

Oh, people, please.
There is no problem. So it is a waste of time trying to solve
this non-problem.

If the device transmits 36 bytes, then we have 36 bytes.
What are these bytes used for? To get a vendor name.
A SCSI standard lawyer might wish to distinguish the case
where 8 blacks or NULs is padding, from the case where
these 8 blanks or NULs is the actual vendor name, but
this distinction does not matter at all for our purposes.

Andries


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: inquiry in scsi_scan.c

[Doug Ledford]

On Mon, Jan 06, 2003 at 04:46:47PM -0800, Matthew Dharm wrote:
> On Mon, Jan 06, 2003 at 05:23:22PM -0500, Doug Ledford wrote:
> [ snipped my comments ]
>
> Okay, so what about sbp2, where this sort of thing is also common?  Why not
> just fix it at the SCSI layer?

How are you wanting to fix it?  The infrastructure for doing this does not
currently exist in the mid layer code.  It would have to be added.  And it
would have to be added in a way that was reliable.  Ideas?
 
> > Except that if a device *does* transfer 36 bytes and then lies and says it 
> > only transferred 5 then we are missing information that might actually be 
> > usefull, hence the reason to set the transfer length up to the real amount 
> > transferred (and BTW, I would only do this for INQUIRY responses, for 
> > anything else the device is simply too buggy to live if it lies about the 
> > transfer length).
> 
> First, I think this is a bogus situation.  If we reqest 36, get X, and
> indicate a total of 5, then we should look at the X we got.  And that has
> to be indicated by resid.

I disagree.  For a compliant SCSI device, it's legal for it to return all
36 bytes of data, but only have the first 5 contain anything and the rest
all be NULL pad bytes and to put 0 into the extra data field.  We are
*suppossed* to be able to rely upon that extra data field being reliable.  
Just because sbp2 and usb scsi device manufacturers are such half-wit
shops that they hire entry level java programmers that couldn't write to a
standard to save their mother's lives doesn't mean that we should be
wrecking the scsi standards at the core level to compensate.

The only way to fix this up (somewhat) reliably as far as I can tell, at
the mid layer, would involve pre-clearing the INQUIRY return area then
issuing the command.  Upon command completion, check to see if extra data
length byte + 5 == cmd->length - cmd->residual.  If not, then check if
there are non-0 bytes beyond the end of the indicated extra data area.  
If so, assume real data length is cmd->length - cmd->residual and if not
then assume extra data length was correct.  

HOWEVER!  This does require changing all the lldd to set cmd->residual.  
This is currently not done, as cmd->residual is optional.  Low level
device drivers are only required to return an error condition when the
actual transfer is < cmd->underflow, they aren't required to set
cmd->residual ever.

HOWEVER2!  This is also just a heuristic and it could be fooled.

> The argument that many HBAs don't set resid just doesn't hold water with
> me.  Just because other drivers are broken, we should break more things
> instead of fixing the problem?

First off, the other drivers aren't broken.  Cmd->residual was added 
about a year or two ago as an ad hoc change to improve CD burning.  It was 
never officially added to the SCSI core API as a requirement in any 
driver.

Besides, we *aren't* talking about fixing a problem.  We are talking about
ignoring data we are suppossed to be able to rely upon to be accurate.  
Ignoring return data should only be done if you have a reasonable
suspicion that the data is wrong.  In usb, that appears to be the case.  
In real scsi devices, that is not the case.  Hence, the location of the
proper fix is, IMHO, in the usb stack (share it with spb2 via a library
call if you wish, but I don't think the scsi core should be doing it).


-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: Re: inquiry in scsi_scan.c

[Alan Stern]

On Mon, 6 Jan 2003, Doug Ledford wrote:

> On Mon, Jan 06, 2003 at 04:46:47PM -0800, Matthew Dharm wrote:
> > On Mon, Jan 06, 2003 at 05:23:22PM -0500, Doug Ledford wrote:
> > > Except that if a device *does* transfer 36 bytes and then lies and says it 
> > > only transferred 5 then we are missing information that might actually be 
> > > usefull, hence the reason to set the transfer length up to the real amount 
> > > transferred (and BTW, I would only do this for INQUIRY responses, for 
> > > anything else the device is simply too buggy to live if it lies about the 
> > > transfer length).
> > 
> > First, I think this is a bogus situation.  If we reqest 36, get X, and
> > indicate a total of 5, then we should look at the X we got.  And that has
> > to be indicated by resid.
> 
> I disagree.  For a compliant SCSI device, it's legal for it to return all
> 36 bytes of data, but only have the first 5 contain anything and the rest
> all be NULL pad bytes and to put 0 into the extra data field.  We are
> *suppossed* to be able to rely upon that extra data field being reliable.  
> Just because sbp2 and usb scsi device manufacturers are such half-wit
> shops that they hire entry level java programmers that couldn't write to a
> standard to save their mother's lives doesn't mean that we should be
> wrecking the scsi standards at the core level to compensate.

Hmm.  Sounds like Doug is trying to have it both ways.  He wants to be
able to handle the case of a device that transfers 36 bytes but only
indicates 5, where the remaining 31 bytes are valid and contain useful
information (a broken device).  He also wants to handle the case of a
device that transfers 36 bytes and only indicates 5, where the remaining
31 bytes only contain padding (legal according to the SCSI spec).  It
seems clear that the driver doesn't have enough information to distinguish
these cases by itself.

How about this as a compromise?  Have the fix_inquiry_data() routine in
storage/protocol.c adjust the additional-length byte if it indicates less
data than actually got transferred (and maybe also < 36 bytes), _unless_
an unusual_devs.h flag bit is set (something like
US_FL_DONT_FIX_INQUIRY_LENGTH).  This flag would only be needed for
devices that transmit useless padding, and presumably these are much rarer
than the brain-dead devices that have an invalid additional-length byte.
In fact, maybe there aren't any examples of any such USB storage devices, 
in which case the flag would be unnecessary.

Alan Stern



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Re: inquiry in scsi_scan.c

[Andries.Brouwer]

> In the case reported, the problem was

Ha, Alan - it is possible that the two of you are referring
to different things.

I mentioned two devices, both return 36 bytes when asked for
36 bytes, but the first has 0 in the additional length field
(thus reports length 5), the second has 32 in the additional
length field (thus reports length 37).
This second device, when asked for 37 bytes, still only returns 36.

Andries


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Re: inquiry in scsi_scan.c

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

On Mon, Jan 06, 2003 at 08:18:45PM +0100, Andries.Brouwer@cwi.nl wrote:
> > In the case reported, the problem was
> 
> Ha, Alan - it is possible that the two of you are referring
> to different things.

That confusion is definatly happening.

> I mentioned two devices, both return 36 bytes when asked for
> 36 bytes, but the first has 0 in the additional length field
> (thus reports length 5), the second has 32 in the additional
> length field (thus reports length 37).
> This second device, when asked for 37 bytes, still only returns 36.

The first case:  If the additional length indicates < 36 bytes, we should
never issue the second request (which is where this device choked).  This
should be a sanity check in scsi_scan.c, and it works for reasons I've
previously outlined.

The second case:  This is a bad device.  A classic off-by-one error.  But
what can usb-storage do?  We don't know that the device is bad.  But,
focusing on this case, what happens?  Short data is returned... if the
resid field is set to indicate this, then scsi_scan.c should be able to do
something sane here.

Perhaps the "best" fix here is to simply make scsi_scan.c only send 36 byte
inquiry requests if the bus is 'emulated'.  That would solve a world of
problems....

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

God, root, what is difference?
					-- Pitr
User Friendly, 11/11/1999

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-usb-devel] Re: inquiry in scsi_scan.c

[Luben Tuikov]

Matthew Dharm wrote:
> 
> Perhaps the "best" fix here is to simply make scsi_scan.c only send 36 byte
> inquiry requests if the bus is 'emulated'.  That would solve a world of
> problems....

When scsi_scan.c does it's own scanning for SCSI Core, maybe it's best to
ignore 36 < INQUIRY_DATA_LEN < 57, since this is just vendor specific
data and SCSI Core is not interested in it.

In descriptive-C this looks like this:

</issue a 36 byte buffer INQUIRY/>
</now dissect:/>

int bytes_got = max(bytes_requested - cmd->resid, 0);

if (31 < buffer[4] && buffer[4] < 52) {
	/* we don't care, do not issue another INQUIRY */	
else if (buffer[4] >= 52) {
	bytes_requested = 5+buffer[4];
	/* issue another INQUIRY to get the additional flags, */
	/* plus any version descriptors if available */
	</insert code here/>
	bytes_got = max(bytes_requested - cmd->resid, 0);
}

if (bytes_got != buffer[4]+5) {
	/* let's rely on the transport to have correctly set */
	/* cmd->resid and report a broken device server */
	</insert code here/>
}

/* Now we rely on bytes_got */

</rest of scanning code/>

-- 
Luben

Re: Re: inquiry in scsi_scan.c

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

I'm told this is a bad idea because there are some HBA which snoop the
INQUIRY data.  Since I don't know how that snooping works, I can't comment
further.

Matt

On Mon, Jan 06, 2003 at 03:49:08PM -0500, Luben Tuikov wrote:
> Matthew Dharm wrote:
> > 
> > Perhaps the "best" fix here is to simply make scsi_scan.c only send 36 byte
> > inquiry requests if the bus is 'emulated'.  That would solve a world of
> > problems....
> 
> When scsi_scan.c does it's own scanning for SCSI Core, maybe it's best to
> ignore 36 < INQUIRY_DATA_LEN < 57, since this is just vendor specific
> data and SCSI Core is not interested in it.
> 
> In descriptive-C this looks like this:
> 
> </issue a 36 byte buffer INQUIRY/>
> </now dissect:/>
> 
> int bytes_got = max(bytes_requested - cmd->resid, 0);
> 
> if (31 < buffer[4] && buffer[4] < 52) {
> 	/* we don't care, do not issue another INQUIRY */	
> else if (buffer[4] >= 52) {
> 	bytes_requested = 5+buffer[4];
> 	/* issue another INQUIRY to get the additional flags, */
> 	/* plus any version descriptors if available */
> 	</insert code here/>
> 	bytes_got = max(bytes_requested - cmd->resid, 0);
> }
> 
> if (bytes_got != buffer[4]+5) {
> 	/* let's rely on the transport to have correctly set */
> 	/* cmd->resid and report a broken device server */
> 	</insert code here/>
> }
> 
> /* Now we rely on bytes_got */
> 
> </rest of scanning code/>
> 
> -- 
> Luben
> 

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

Would you mind not using our Web server? We're trying to have a game of 
Quake here.
					-- Greg
User Friendly, 5/11/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]