I would have sworn we already patched this, but now I can find no record of
it.
Attached is a one-liner patch to scsi_scan.c, which changes the length of
the INQUIRY data request from 255 bytes to 36 bytes. This subtle change
makes Linux act more like Win/MacOS and other popular OSes, and reduces
incompatibility with a broad range of out-of-spec devices that will simply
die if asked for more than the required minimum of 36 bytes.
Did we patch this before? I can't find it in the l-k archives, but I'm
almost positive we have. I remeber this because this problem plagues some
USB devices, which just crash if you ask for more than 36 bytes of data.
Patch is attached. Please apply.
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
G: Let me guess, you started on the 'net with AOL, right?
C: WOW! d00d! U r leet!
-- Greg and Customer
User Friendly, 2/12/1999
Hi Matthew,
A so-claimed SCSI device that fails INQUIRY is not a SCSI device. That is
as simple as that. :-)
You didn't look into all the SCSI code that is interested in INQUIRY data.
Some low-level drivers also snoop the INQUIRY data, especially when they
want to cleverly support newer features, as Ultra-160 transfers for
example.
If you really need to use Linux SCSI for your 'almost but not really SCSI
devices', you may for example, either:
- Maintain a patch for your personnal usage,
- Or propose some boot option that will do the trick.
G?rard.
PS: Indeed, the 255 bytes for the length of INQUIRY data was not that
clever, even if it is absolutely correct.
On Tue, 13 Nov 2001, Matthew Dharm wrote:
> Rob --
>
> This patch doesn't prevent another application from getting more INQUIRY
> bytes. What it does change is how much data the SCSI scanning loop looks
> for. That data is requested, and then thrown away. It's not kept around
> for anything.
>
> If it were kept, I'd agree with you. But it's not. Some useful data is
> copied out of the INQUIRY result, and then the buffer is overwritten by the
> next probing request.
>
> I can't see any code in the SCSI scanning section that looks beyond the
> first 36 bytes.
>
> Also, some devices just die if the INQUIRY is anything but 36-bytes. Since
> all the data beyond the first 36 is considered vendor-specific, I would
> expect a driver to _check_ the first 36 bytes to see if this is an
> apropriate device, and then (and only then) request more data.
>
> Matt
>
> On Tue, Nov 13, 2001 at 08:49:09PM +0100, Rob Turk wrote:
> > "Matthew Dharm" <[email protected]> wrote in message
> > news:[email protected]...
> >
> > >Attached is a one-liner patch to scsi_scan.c, which changes the length of
> > >the INQUIRY data request from 255 bytes to 36 bytes. This subtle change
> > >makes Linux act more like Win/MacOS and other popular OSes, and reduces
> > >incompatibility with a broad range of out-of-spec devices that will simply
> > >die if asked for more than the required minimum of 36 bytes.
> >
> > >Matt
> >
> > Matt,
> >
> > Many devices have useful information in the bytes beyond 36. Media changers from
> > various vendors are starting to use byte 55 bit 0 to flag if a barcode scanner
> > is present. Other devices have revision levels and/or serial numbers there.
> >
> > Getting more than 36 bytes should not be a problem for any device. The root
> > problem seems to be that 255 is an odd number. On Wide-SCSI, a lot of devices
> > have difficulty handling odd byte counts as they have to use additional
> > messaging to flag the residue in the last 16-bit transfer. Also, the IDE-SCSI
> > layer has trouble, as the IDE spec doesn't allow odd byte transfers at all. I've
> > experienced issues with IDE devices that had to have their firmware patched just
> > to deal with the Linux odd-byte request. Maybe a better change would be to use
> > 64 or 128 byte requests. Your thoughts?
> >
> > Rob
>
> --
> Matthew Dharm Home: [email protected]
> Maintainer, Linux USB Mass Storage Driver
>
> It's not that hard. No matter what the problem is, tell the customer
> to reinstall Windows.
> -- Nurse
> User Friendly, 3/22/1998
>
"Matthew Dharm" <[email protected]> wrote in message
news:[email protected]...
>Attached is a one-liner patch to scsi_scan.c, which changes the length of
>the INQUIRY data request from 255 bytes to 36 bytes. This subtle change
>makes Linux act more like Win/MacOS and other popular OSes, and reduces
>incompatibility with a broad range of out-of-spec devices that will simply
>die if asked for more than the required minimum of 36 bytes.
>Matt
Matt,
Many devices have useful information in the bytes beyond 36. Media changers from
various vendors are starting to use byte 55 bit 0 to flag if a barcode scanner
is present. Other devices have revision levels and/or serial numbers there.
Getting more than 36 bytes should not be a problem for any device. The root
problem seems to be that 255 is an odd number. On Wide-SCSI, a lot of devices
have difficulty handling odd byte counts as they have to use additional
messaging to flag the residue in the last 16-bit transfer. Also, the IDE-SCSI
layer has trouble, as the IDE spec doesn't allow odd byte transfers at all. I've
experienced issues with IDE devices that had to have their firmware patched just
to deal with the Linux odd-byte request. Maybe a better change would be to use
64 or 128 byte requests. Your thoughts?
Rob
Rob --
This patch doesn't prevent another application from getting more INQUIRY
bytes. What it does change is how much data the SCSI scanning loop looks
for. That data is requested, and then thrown away. It's not kept around
for anything.
If it were kept, I'd agree with you. But it's not. Some useful data is
copied out of the INQUIRY result, and then the buffer is overwritten by the
next probing request.
I can't see any code in the SCSI scanning section that looks beyond the
first 36 bytes.
Also, some devices just die if the INQUIRY is anything but 36-bytes. Since
all the data beyond the first 36 is considered vendor-specific, I would
expect a driver to _check_ the first 36 bytes to see if this is an
apropriate device, and then (and only then) request more data.
Matt
On Tue, Nov 13, 2001 at 08:49:09PM +0100, Rob Turk wrote:
> "Matthew Dharm" <[email protected]> wrote in message
> news:[email protected]...
>
> >Attached is a one-liner patch to scsi_scan.c, which changes the length of
> >the INQUIRY data request from 255 bytes to 36 bytes. This subtle change
> >makes Linux act more like Win/MacOS and other popular OSes, and reduces
> >incompatibility with a broad range of out-of-spec devices that will simply
> >die if asked for more than the required minimum of 36 bytes.
>
> >Matt
>
> Matt,
>
> Many devices have useful information in the bytes beyond 36. Media changers from
> various vendors are starting to use byte 55 bit 0 to flag if a barcode scanner
> is present. Other devices have revision levels and/or serial numbers there.
>
> Getting more than 36 bytes should not be a problem for any device. The root
> problem seems to be that 255 is an odd number. On Wide-SCSI, a lot of devices
> have difficulty handling odd byte counts as they have to use additional
> messaging to flag the residue in the last 16-bit transfer. Also, the IDE-SCSI
> layer has trouble, as the IDE spec doesn't allow odd byte transfers at all. I've
> experienced issues with IDE devices that had to have their firmware patched just
> to deal with the Linux odd-byte request. Maybe a better change would be to use
> 64 or 128 byte requests. Your thoughts?
>
> Rob
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
It's not that hard. No matter what the problem is, tell the customer
to reinstall Windows.
-- Nurse
User Friendly, 3/22/1998
> Attached is a one-liner patch to scsi_scan.c, which changes the length of
> the INQUIRY data request from 255 bytes to 36 bytes. This subtle change
> makes Linux act more like Win/MacOS and other popular OSes, and reduces
> incompatibility with a broad range of out-of-spec devices that will simply
> die if asked for more than the required minimum of 36 bytes.
It breaks sane, it breaks some cd burning tools. We really need all of it
I think
> This patch doesn't prevent another application from getting more INQUIRY
> bytes. What it does change is how much data the SCSI scanning loop looks
> for. That data is requested, and then thrown away. It's not kept around
> for anything.
>
> If it were kept, I'd agree with you. But it's not. Some useful data is
> copied out of the INQUIRY result, and then the buffer is overwritten by the
> next probing request.
Ok I need to double check that. My merge of the 255 has a note saying for
fixing sane, but that doesnt mean someone didnt overfix the matter
Hi Rob.
> Getting more than 36 bytes should not be a problem for any device.
> The root problem seems to be that 255 is an odd number. On
> Wide-SCSI, a lot of devices have difficulty handling odd byte counts
> as they have to use additional messaging to flag the residue in the
> last 16-bit transfer. Also, the IDE-SCSI layer has trouble, as the
> IDE spec doesn't allow odd byte transfers at all. I've experienced
> issues with IDE devices that had to have their firmware patched just
> to deal with the Linux odd-byte request.
> Maybe a better change would be to use 64 or 128 byte requests. Your
> thoughts?
Probably the best option would be to tweak this to 256 if that is
available, or 252 if not - I seem to remember there's at least one
SCSI drive that can't handle other than multiples of 4 bytes.
Best wishes from Riley.
I'm hard pressed to come up with a reason that changing the SCSI probing
would affect SANE...
If you've found a merge of 255 back into the kernel, then that means that,
for a while, my 36 patch _was_ in place. Was that (overfix) the only
reason it was reverted to 255 after a while?
Matt
On Tue, Nov 13, 2001 at 11:26:27PM +0000, Alan Cox wrote:
> > This patch doesn't prevent another application from getting more INQUIRY
> > bytes. What it does change is how much data the SCSI scanning loop looks
> > for. That data is requested, and then thrown away. It's not kept around
> > for anything.
> >
> > If it were kept, I'd agree with you. But it's not. Some useful data is
> > copied out of the INQUIRY result, and then the buffer is overwritten by the
> > next probing request.
>
> Ok I need to double check that. My merge of the 255 has a note saying for
> fixing sane, but that doesnt mean someone didnt overfix the matter
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
We can customize our colonels.
-- Tux
User Friendly, 12/1/1998