From: Matthew Dharm <mdharm-scsi@one-eyed-alien.net>
To: Andries.Brouwer@cwi.nl
Cc: luben@splentec.com, stern@rowland.harvard.edu,
linux-scsi@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net
Subject: Re: Re: inquiry in scsi_scan.c
Date: Mon, 6 Jan 2003 11:22:59 -0800 [thread overview]
Message-ID: <20030106112259.B13916@one-eyed-alien.net> (raw)
In-Reply-To: <UTC200301061918.h06JIjB21034.aeb@smtp.cwi.nl>; from Andries.Brouwer@cwi.nl on Mon, Jan 06, 2003 at 08:18:45PM +0100
[-- 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 --]
next prev parent reply other threads:[~2003-01-06 19:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-06 19:18 Re: inquiry in scsi_scan.c Andries.Brouwer
2003-01-06 19:22 ` Matthew Dharm [this message]
2003-01-06 20:49 ` [linux-usb-devel] " Luben Tuikov
2003-01-06 21:03 ` James Bottomley
2003-01-06 21:05 ` Matthew Dharm
2003-01-06 21:16 ` [linux-usb-devel] " Luben Tuikov
2003-01-06 22:07 ` Doug Ledford
2003-01-06 22:10 ` Doug Ledford
2003-01-06 22:23 ` Doug Ledford
2003-01-07 0:46 ` Matthew Dharm
2003-01-07 3:42 ` Doug Ledford
2003-01-07 15:15 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2003-01-06 22:30 Cress, Andrew R
2003-01-06 22:40 ` Luben Tuikov
2003-01-07 16:37 Andries.Brouwer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030106112259.B13916@one-eyed-alien.net \
--to=mdharm-scsi@one-eyed-alien.net \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=luben@splentec.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox