Re: [BUG] Regression in Linux 5.4.17 for JMicron JMS566 enclosure

[Cyril Roelandt <tipecaml@gmail.com>]

On 2020-04-17 16:06, Alan Stern wrote:
> On Fri, 17 Apr 2020, Cyril Roelandt wrote:
> 
> > On 2020-04-15 21:21, Alan Stern wrote:
> 
> > > > I do not really mind not being able to use uas, however I would like to
> > > > be able to mount my partitions using usb-storage.
> > > 
> > > It's entirely possible that the blacklisting is not necessary any more.  
> > > After all, it was added four and a half years ago; the kernel has
> > > improved since then.  I guess you're not in a position to test this,
> > > but maybe Steve Ellis or Takeo Nakayama is...?
> > > 
> > > Does 5.3 work if you add a similar blacklist entry?
> > 
> > I cloned Linus' tree, and cherry-picked
> > bc3bdb12bbb3492067c8719011576370e959a2e6 on top of v5.3, rebuilt the
> > kernel and rebooted: I had the exact same issue.
> > 
> > > 
> > > Can you collect usbmon traces showing what happens with both uas and
> > > usb-storage?  Perhaps different sequences of commands get sent to the
> > > drive with the two drivers.
> > 
> > Here it is:
> 
> Two things.  First, you started the usbmon traces _after_ plugging in
> the drive.  As a result the traces do not contain a complete record of
> all the transfers between the computer and the drive; it's possible
> that something in the missing portions is responsible for your problem.
> For example, why does your uas log include a line ("[sdb] 4096-byte 
> physical blocks") that is missing in the usb-storage log?

Oh, sorry, I'm new to this. The logs became really long, so I've taken
the liberty of pasting them to paste.debian.net. I captured what
happened when plugging the WD drive and running "mount".

- With a 5.3 kernel, using uas: http://paste.debian.net/1141035/
- With a 5.4 kernel, using usb-storage: http://paste.debian.net/1141036/
- With a 5.4 kernel, using usb-storage, using a similar enclosure that
  works as expected (the Icy Box IB-268U3-B, which has the same product
  ID and vendor ID but a different bcdDevice: 2.03 instead of
  1.14): http://paste.debian.net/1141037/


> [...]
> Of course, this makes no sense because the drive had no problem
> understanding the exact same command when it was sent by uas.
> 
> At this point, all I can say is that something about the combination of
> the enclosure and the drive works with the UAS transport but not with
> the USB Mass-Storage transport.  As far as we can see from the usbmon 
> traces, the kernel isn't doing anything wrong.

I wrote in my original message that the enclosure worked fine with a
Fujitsu drive, but upon further testing this proved inexact: it worked
with an NTFS partition on said drive. Once I formatted it to ext4, it
started failing as well. To recap, when using usb-storage this is what
happens:

IB273 + WD Blue 1TB   (ext4)   -> Broken
IB273 + Fujitsu 250GB (ext4)   -> Broken
IB273 + Fujitsu 250GB (NTFS)   -> OK
IB268 + WD1TB         (ext4)   -> OK

Where:
- IB273 has idVendor=357d, idProduct=7788 and bcdDevice= 1.14
- IB268 has idVendor=357d, idProduct=7788 and bcdDevice= 2.03


Thanks for your help,
Cyril Roelandt.