> 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 ca
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
On Mon, Jan 06, 2003 at 05:23:22PM -0500, Doug Ledford wrote:
> On Mon, Jan 06, 2003 at 11:22:59AM -0800, Matthew Dharm wrote:
> >
> > 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
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.
T
]]
Sent: Monday, January 06, 2003 4:06 PM
To: Luben Tuikov
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
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&#
Matthew Dharm wrote:
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.
I do, in my own LLDDs. If anything the additional length might increase.
Others snoop it for their own awareness of the
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 ma
[EMAIL PROTECTED] said:
> bytes_got = max(bytes_requested - cmd->resid, 0);
[...]
> /* let's rely on the transport to have correctly set */
> /* cmd->resid and report a broken device server */
>
I'm afraid that for a large number of HBAs in the tree SCpnt->resid just isn
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, sinc
On Sun, Jan 05, 2003 at 10:42:46PM +0100, [EMAIL PROTECTED] wrote:
> Zwane Mwaikambo writes:
>
> > This looks related to something i also bumped into
> >
> > scsi scan: host 2 channel 0 id 0 lun 0 identifier too long
>
> Sounds familiar. Please try the below (on 2.5.54).
>
> Andries
>
Instead
On Mon, Jan 06, 2003 at 08:18:45PM +0100, [EMAIL PROTECTED] 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 fo
> 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 addi
On Mon, 6 Jan 2003, Luben Tuikov wrote:
> In this most recent case reported, this looks very similar to
> overflow residual, but not quite the same. I.e. *more* data is
> actually immediately available (in the buffer) than *we requested* or can
> find out by other means (i.e. checking the ADDITION
Alan Stern wrote:
The SCSI code has no means of knowing the actual length transferred,
so has no choice but to believe the length byte in the reply.
But the USB code does the transferring itself, and knows precisely
how many bytes were transferred. If 36 bytes were transferred and
the additional
On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote:
> The SCSI code has no means of knowing the actual length transferred,
> so has no choice but to believe the length byte in the reply.
> But the USB code does the transferring itself, and knows precisely
> how many bytes were transferred. If 36 bytes wer
[EMAIL PROTECTED] wrote:
There are at least four replies:
The factual: It seems you are unaware of the present USB storage code.
For many devices the INQUIRY response is entirely fabricated.
I'm aware of this, but you were complaining of a new device
which you got, so I assumed the INQUIRY res
Zwane Mwaikambo writes:
> This looks related to something i also bumped into
>
> scsi scan: host 2 channel 0 id 0 lun 0 identifier too long
Sounds familiar. Please try the below (on 2.5.54).
Andries
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/scsi/scsi_scan.c
b/drivers/scsi/sc
[EMAIL PROTECTED] wrote:
>
> The SCSI code has no means of knowing the actual length transferred,
> so has no choice but to believe the length byte in the reply.
> But the USB code does the transferring itself, and knows precisely
> how many bytes were transferred. If 36 by
On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote:
> The SCSI code has no means of knowing the actual length transferred,
> so has no choice but to believe the length byte in the reply.
> But the USB code does the transferring itself, and knows precisely
> how many bytes were transferred. If 36 bytes wer
[EMAIL PROTECTED] wrote:
The SCSI code has no means of knowing the actual length transferred,
so has no choice but to believe the length byte in the reply.
But the USB code does the transferring itself, and knows precisely
how many bytes were transferred. If 36 bytes were transferred and
the addi
Matthew Dharm writes:
> Instead of fixing this in usb-storage, I think I would rather make
> scsi_scan.c just assume a minimum of 36.
No, because (for SCSI-1) the minimum is 5.
> Or, put another way, if the first request indicates less than 36, why
> should we do a second request? We already ha
Instead of fixing this in usb-storage, I think I would rather make
scsi_scan.c just assume a minimum of 36.
Or, put another way, if the first request indicates less than 36, why
should we do a second request? We already have all the data...
Matt
On Sat, Jan 04, 2003 at 04:07:51AM +0100, [EMAIL
By the way - there are other cases where the INQUIRY length is
reported incorrectly. Another device does:
usb_stor_bulk_transfer_buf(): xfer 37 bytes
00 80 02 02 20 00 00 00 65 55 53 42 20 20 20 20
43 6F 6D 70 61 63 74 20 46 6C 61 73 68 20 20 20
00 00 00 00
usb-storage: Status code 0; transferr
Matthew Dharm writes:
> There should probably be a sanity check to never ask for INQUIRY
> less than 36 bytes. I thought there used to be such a thing
As Doug also points out, we ask for 36, but there is no
guarantee that we get what we ask for.
> Actually, 5 isn't minimal... it's sub-minim
24 matches
Mail list logo
