Re: [usb-storage] mode sense blacklist how

[Pat LaVarre <p.lavarre@ieee.org>]

> The only really important question IMHO is
> how come SG_IO is not interruptible.

Yes, now being pursued by Doug G in this thread.

> > In the log I see this command repeated, time and again.  Did you ask for
> > this command repeatedly yourself, or is it the code of SG_IO and below
> > that is so helpfully retrying?
> 
> That wasn't me. I see these commands were sent *after* the device has 
> been unplugged. It must've been SCSI layer.

This also could matter.  In our kernel code who wrongly thinks we gave
permission to retry SG_IO?  This evidence echoes someone else's - may
have been Patrick M - who saw mode sense stuttering.  I don't remember
if that was different (rude mode sense from the kernel) or the same
(rude mode sense via SG_IO from plscsi).

> Anyway, it must be obvious by now that the device is broken or shall
> we say proprietary. There is a quick workaround already in place. I'd
> say blacklist it in unusual_devs and be done with it.

Not broken.

This device explicitly self-identifies itself as a proprietary kind of
SCSI via bInterfaceSubClass = xFF and also the almost-proprietary kind
of SCSI over USB that is bInterfaceProtocol != x50.

No separate blacklist needed.  Recently near here I think I heard:

We of usb-storage are instead choosing to blacklist all the reserved
bInterfaceSubClass codes altogether.  Already we blacklist such devices
in that we don't try talking unless they appear in unusual_devs.  Now
also we won't try non-Microsoft mode sense even if they do appear in
unusual_devs.

> > the plscsi workaround: -X time 5 0. 
> > Does that work for you?  
> 
> Yes, ... Still, ... device ... must be unplugged ...

Curious.  If the mode senses that work aren't the first mode senses that
Windows tries, then the resets of Windows must be working ...

> try more MODE SENSE(10) ... finally found some that work:
> 
> ./plscsi /dev/sg1 -v -p -X time 10 0 -i xC0 -x "5A 00 3F 00 00 00 00 00 C0 00"
> produces the following output:
> 
> x 00000000 5A 00 3F:00:00:00 00 00:C0 00 .. .. .. .. .. .. "Z@?@@@@@@@"
> x 00000000 00:32:00:00 00:00:00:00 05:1E:00:12 04:20:02:00 "@2@@@@@@E^@RD B@"
> x 00000010 01:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "A@@@@@@@@@@@@@@@"
> x 00000020 00:00:00:00 00:B4:00:00 1B:0A:C0:00 00:00:00:00 "@@@@@4@@[J@@@@@@"
> x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
> ...
> x 000000B0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"

Ah.  Eight byte header claiming x34 bytes available.  No optional block
descriptor.  x20 bytes of page x05 for boot H:S:C.  x0C bytes of page
x1B to please Windows.    x 8 + 20 + 0C = 34, good.

> // 0 = plscsi.main exit int
> 
> It looks like the device does support MODE SENSE(10) for pages 5 and 1B only.

Perhaps that is all that PC boot BIOS and Windows require.  This could
be a sample of design-by-test: edit, compile, test, ship when it does
not crash.  Do you know if the device firmware is upgradable?

> "5A 00 05 00 00 00 00 00 C0 00" and "5A 00 1B 00 00 00 00 00 C0 00" also work.
> 
> There is not much useful info on those 2 pages, what was the point 
> of implementing them I wonder?

t10.org as we speak is hashing over the value or not of reporting a
fictional C:H:S geometry in the mode page x05 that can report C:H:S up
to about 8 GiB.

Page x1B I don't remember the t10.org name of but it appears in Windows
traces, so someone on Earth thinks it can be useful.  Name might be
something like "power conditions".

> > Have you tried `modprobe -r usb-storage`?
> "Module in use"
> Not entirely unexpected since plscsi holds an open handle at this point.

I'm sure I'm enough of a kernelnewbie to be deeply confused here, but I
don't understand why we can kill the plscsi process without gaining
permission to kill the SG_IO.
 
> > Adding -v might tell us more.
>
> Not really:) It just shows the command going down and that's it.

Thanks for saying, now I feel less bad about not suggesting -v to begin
with.

> > Here we see "auto-sense" "code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0".
> > 
> > In the t10.org English, x 5 24 means cdb[0] opcode understood, but whole
> > cdb not understood.  x 5 20 means cdb[0] opcode not understood.
> > 
> > This result suggests, without guaranteeing, that the vendor-specific
> > bInterfaceSubClass = xFF SCSI of this device includes some cdb's that
> > begin with op x1A Mode Sense (6).
> 
> Hmm, I tried MODE SENSE(6) with the same pages (5,1B and 3F) that worked 
> with MODE SENSE(10) and I've got the same error: x 5 24.

Ouch, maybe this device is creatively reporting x 5 24 to mean x 5 20.

Pat LaVarre