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.
> On Tue, Nov 13, 2001 at 08:49:09PM +0100, Rob Turk wrote:
> > "Matthew Dharm" <email@example.com> wrote in message
> > news:cistron.20011113102106.A23110@one-eyed-alien.net...
> > >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: firstname.lastname@example.org
> 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 email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/