On Mon, 18 Jan 2016, Calum Mackay wrote: > I'm getting UAS errors using a USB 3.0 SATA enclosure (StarTech > S3510BMU33ET; 174c:55aa) > > This appears to have an ASM1053 chipset which, as far as my reading of > uas_use_uas_driver() goes, should have a working UAS providing we > restrict the size of the transfer? > > i.e. MaxPower is 36, and MaxStreams is 16, which should imply ASM1053, > with working UAS, but with US_FL_MAX_SECTORS_240. > > > That should be done for us, according to the code, but just to be sure, > as I'm using the Debian (unstable) kernel 4.3.3, I added the > US_FL_MAX_SECTORS_240 quirk myself: > > getz $ grep usb-storage /etc/modprobe.d/uas-blacklist.conf > options usb-storage quirks=174c:55aa:g > > [but is that still used if UAS is active? I get no "Quirks match" > message for 'g', unlike I do for UAS disable 'u'] usb-storage prints that message but uas doesn't. It probably should. While uas ignores most of the possible quirk settings, it does pay attention to the MAX_SECTORS_240 flag. > With that 'g' in place, I get reams of UAS errors/resets, and the device > is unusable. > > If I change the quirk to 'u', to disable UAS: > > options usb-storage quirks=174c:55aa:u > > then things work, but the performance is dire (e.g. 8MB/s writes). Even with USB-2 (High Speed) you should get 30 MB/s or more. Clearly something else is wrong. You should collect a usbmon trace (see Documentation/usb/usbmon.txt). Start with debugging usb-storage and work your way up to uas. > Should this particular device be working? It doesn't seem to, so should > the detection logic in uas_use_uas_driver() be disabling UAS for my device? It probably should work. I don't know anything about that particular device, however. > Or am I missing something? > > The disk in the enclosure is a WD30EZRX (WD Green 3TB) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
