On Sun, Aug 23, 2020 at 03:30:25AM +0200, Cyril Roelandt wrote: > Hello, > > On 2020-08-18 10:57, Alan Stern wrote: > > Somehow that commit is causing usb-storage to go crazy. You're going > > to have to do some debugging to find out why. > > > > Here's what to look for in drivers/usb/storage/usb.c: > > > > Is storage_probe() getting called at all? > > Yes. > > > > > If it is, it doesn't seem to get as far as calling > > usb_stor_probe1(). Can you find out where it goes off the > > rails and why? > > Yes. I added a bunch of calls to printk[1] and noticed the following new > lines in dmesg: > > [Fri Aug 21 23:02:42 2020] [+] Entering storage_probe > [Fri Aug 21 23:02:42 2020] [+] Using uas driver > > So basically, the kernel realizes that UAS cannot be used, tries to use > usb-storage instead, and then usb-storage says "well, this device should > be using UAS, I'm not going to handle it". Somehow, we forget that UAS > is broken for this device along the way. > > I commented out the call to uas_use_uas_driver()[2] and was able to see > my partitions, mount them, read and write data. Everything works as > expected. > > Do you have any idea why usb-storage may be led to believe UAS is > suitable for this enclosure? Yes; it looks like the problem is that there are entries for this device in both unusual_devs.h and unusual_uas.h -- and it doesn't help that the two entries aren't identical. The unusual_devs.h entry tells usb-storage not to use FUA, but it doesn't rule out the uas driver. And since the device claims to support UAS, usb-storage bows out. But then the unusual_uas.h entry tells uas not to handle the drive, so the end result is that it doesn't get handled at all. To fix the immediate problem you should add the US_FL_IGNORE_UAS flag to the entry in unusual_devs.h. Alan Stern
