Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Patrick Mansfield <patmans@us.ibm.com>]

On Wed, Sep 10, 2003 at 12:23:43PM -0400, Alan Stern wrote:

> Is there any feeling about how to handle these ongoing problems with the 
> mode-sense cache page?  There doesn't seem to be any general solution that 
> can work with all USB storage devices.  Some hang when asked to read the 
> entire page; some hang when asked to read just part of the page; some hang 
> when asked to read just the page header.
> 
> What do the SCSI folk have to say about it?

There was at least this thread last April:

http://marc.theaimsgroup.com/?t=104839042700001&r=1&w=2

Matthew had a simple patch so that emulated hosts did not do any (sd.c)
mode-sense cache checks, James had a filter commands patch.

There were changes since then in how the MODE SENSE is handled (sd.c
only?).

In current 2.6 code, the scsi_host emulated flag does nothing, and can
be deleted.

I don't like per-host (or transport) flags or filters that cannot be
modified. They make some sense for hosts that process the scsi commands
(like a RAID card). If you moved a device from one transport to another,
the commands sent to the device should not change: for example, you move
an iSCSI attached device onto your local system via SPI.

IMO we ought to go with two new BFLAGS, one to block the MODE SENSE page 8
(for the cache), and one to block the MODE SENSE page 0x3f (to check the
write protect). 

A per host bflags could be added, and overwritten by per device (devinfo)
settings. I'd rather we black list the broken ones but that does not
appear to be practical. usb-storage could then set the per-host bflag to
include the two new flags.

We still end up sending some non-popular SCSI commands to all SCSI
devices.

Such flags would not stop sg from sending those commands, but that is
postive as well as negative in that you can override what the kernel is
doing via user space (sort of what Pat LaVarre experienced).

Also mentioned in the above thread:

The EVPD code has been removed, and is not an issue.

There is now code to set BLIST_INQUIRY_36 (we can still potentially hang
broken devices before it is set, but you should get a warning, and then
could modify devinfo on the boot/module command line or via proc devinfo).

-- Patrick Mansfield