[lkml]   [2001]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: scsi_scan.c: emulate windows behavior

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

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.


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" <> wrote in message
> >
> >
> > >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:
> 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.074 / U:2.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site