Re: Retirement of CAM_QUIRK_NOSERIAL

Ulrich Spoerlein wrote:
> On Mon, 10.09.2007 at 22:12:52 -0600, Scott Long wrote:
> 
>>All,
>>
>>The attached patch should make CAM behave properly with regard to
>>probing device serial numbers only when the device advertises that
>>it supports it.  It will hopefully eliminate the need for the 
>>CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated 
>>legacy problem that may or may not be possible to fix).  This should
>>especially benefit USB-UMASS devices, where the console output should
>>be less noisy.  It might even make more devices work out-of-the-box.
> 
> 
> While this patch is working fine with my USB/FW HDD enclosure, it breaks
> my MP3 USB stick
> 
> kernel: umass0: <Samsung YP-U2, class 0/0, rev 2.00/10.01, addr 8> on uhub5
> kernel: umass0: BBB reset failed, IOERROR
> kernel: umass0: BBB bulk-in clear stall failed, IOERROR
> kernel: umass0: BBB bulk-out clear stall failed, IOERROR

Is this a regression of something that works without the patch, or is
it something that has never worked?  What happens if you use the
NO_INQUIRY_EVPD quirk instead?

> 
> This stick needs the SHUTTLE_INIT | NO_GETMAXLUN quirk. Perhaps there is some
> interdependencies?

Likely only to the extent that this is a pretty difficult device to deal
with.

> 
> The patch also, does not magically allow me to read retail DVDs through my
> Plextor drive when attached via cd(4), but that is not the goal of the patch
> anyway.

Actually, I was hoping that it would =-)

> 
> It's funny, though. If I quirk this Plextor DVD to NO_INQUIRY, it will attach
> via da(4) (sic!) and suddenly all kinds of DVD media start working!
> 
> umass0: <PLEXTOR DVDR   PX-755A, class 0/0, rev 2.00/4.35, addr 8> on uhub5
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <  > Removable Direct Access SCSI-2 device 
> da0: 40.000MB/s transfers
> da0: 3001MB (1536688 2048 byte sectors: 255H 63S/T 95C)
> 

I'm honestly having a really hard time believing that a device could
claim to support "SCSI" but not support a basic INQUIRY command.  That's
the one command that is absolutely essential to any SCSI device.  What
if you try the NO_INQUIRY_EVPD or FORCE_SHORT_INQUIRY quirks?

Scott