6

According to How can I check whether USB3.0 UASP mode is enabled in Linux?, UASP is not in use on my new HDD enclosure that says it supports UASP.

Also, my motherboard's (ASUS M5A99FX PRO R2.0) manual says:

USB 3.0 Boost ASUS USB 3.0 Boost technology supports UASP (USB Attached SCSI Protocol), the latest USB 3.0 standard. Witht USB 3.0 Boost technology, a USB device’s transmission speed is significantly increased up to 170%, adding to an already impressive fast USB 3.0 transfer speed. ASUS software automatically accelerates data speeds for compatible USB 3.0 peripherals without the need for any user interaction.

So with motherboard support and device support (and Linux support), why isn't UASP being used, and how can I make it be used?

Or perhaps it is being used, and I just don't know how to check it. Relevant output of lsusb -t:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

EDIT
I am running Linux 4.0.8 on Fedora 21 (64-bit).

EDIT 2
Here is the output of lsmod | grep uas:

uas                    24576  0 
usb_storage            65536  1 uas

Here is the all dmesg output generated by turning on the docking station (with a HDD in it):

[173791.566332] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[173791.581802] usb 2-2: New USB device found, idVendor=174c, idProduct=55aa
[173791.581809] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[173791.581814] usb 2-2: Product: ASMT1053
[173791.581818] usb 2-2: Manufacturer: asmedia
[173791.581822] usb 2-2: SerialNumber: 123456789012
[173791.583705] usb-storage 2-2:1.0: USB Mass Storage device detected
[173791.583933] usb-storage 2-2:1.0: Quirks match for vid 174c pid 55aa: 400000
[173791.583981] scsi host11: usb-storage 2-2:1.0
[173792.587494] scsi 11:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 6
[173792.588048] sd 11:0:0:0: Attached scsi generic sg3 type 0
[173792.589870] sd 11:0:0:0: [sdc] Spinning up disk...
[173793.589663] .......ready
[173799.606012] sd 11:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB)
[173799.606599] sd 11:0:0:0: [sdc] Write Protect is off
[173799.606606] sd 11:0:0:0: [sdc] Mode Sense: 43 00 00 00
[173799.607092] sd 11:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[173799.624914]  sdc: sdc2
[173799.626624] sd 11:0:0:0: [sdc] Attached SCSI disk
Community
  • 1
BenjiWiebe
  • 8,854
  • 11
  • 42
  • 65

2 Answers2

6

From looking at uas-detect.h I can see that the ASM1053 chip in your enclosure is indeed supported by the UAS driver (even if it has bugs with large transfers).

You might try modifying your modules.alias file to add support for your device ID. Unfortunately, if depmod is run again by anything on your system you'll have to redo those changes to the modules.alias file.

A second option might be to patch the UAS kernel module to advertise support for your device ID and rebuilding the module. If you did this and push a good patch back upstream, you might even get everyone with your HD enclosure Linux UAS support.

ThatOneDude
  • 2,724
  • 15
  • 18
  • Doesn't modules.alias just tell Linux to load certain drivers if certain device IDs are detected? `uas` *is* already loaded. – BenjiWiebe Aug 15 '15 at 02:04
  • Interestingly, `uas` gets loaded even if I `modprobe -r uas` it, and connect my device to USB 2.0, and turn it on. Without it appearing on `modules.alias`... – BenjiWiebe Aug 15 '15 at 02:27
  • 1
    The driver will work and attach if it thinks it can support the device, and the modules.alias may help it think so. If that doesn't work, you'll need to use the second option to modify the driver so it DOES think it supports the device and will attach. See http://unix.stackexchange.com/questions/26132/how-to-assign-usb-driver-to-device You might also try blacklisting usbstorage and see what the device picks up as a driver... – ThatOneDude Aug 15 '15 at 03:32
  • Blacklisting probably won't work, since `uas` depends on `usb-storage`. But I'm going to try editing the module and recompiling. – BenjiWiebe Aug 15 '15 at 13:36
  • Sorry, this doesn't work. I edited the `uas` module's source code, and `modinfo` now reports that it supports p174Cd55AA, but Linux still uses the usb-storage module. – BenjiWiebe Aug 15 '15 at 14:52
  • What happens if you blacklist the usb-storage module? – ThatOneDude Aug 15 '15 at 15:17
  • It uses it anyways (probably because `uas` requires it, and if I blacklist `uas`, that's defeating the purpose.) – BenjiWiebe Aug 15 '15 at 16:30
  • You get the bounty for all your research and ideas. Enjoy! – BenjiWiebe Aug 15 '15 at 22:11
  • Sorry we weren't able to answer your question. It sure would be nice if you could say "for this exact device load and use this exact driver" but I was not able to find an explicit way to do so. Thanks for the bounty anyway! – ThatOneDude Aug 16 '15 at 00:22
  • 1
    @BenjiWiebe do you found a solution in the meantime? – NKnusperer Apr 15 '16 at 10:34
  • @NKnusperer No. It still only uses usb-storage, not uas... – BenjiWiebe Apr 15 '16 at 18:43
  • The lxr.free-electrons.com link to uas-detect.h given above has moved to https://elixir.bootlin.com/linux/latest/source/drivers/usb/storage/uas-detect.h . – Nathan Aug 08 '19 at 22:30
2

In case anyone with a similar problem stumbles across this thread...

Unlike most device-driver kernel modules, the usb-storage and uas drivers don't work based on a list of known device ids, but instead both use the detection logic found in the uas-detect.h file's uas_use_uas_driver() function which makes a decision based on whether the device claims to support the UAS protocol. (See also this linuxquestions.org thread regarding the device aliases.)

In this case, blacklisting one or the other module won't make any difference; if uas_use_uas_driver() returns true then uas.c will claim it and usb.c will reject it, and the reverse will happen if the function returns false.

(Instead, there is a configuration setting "usb-storage.quirks=VID:PID:u" which can be used to make sure a device does not get claimed by the uas driver, as documented in the The kernel's command line parameters document. [There is no flag to force in the other direction.])

For the OP's issue: the problem is that normally the kernel can straightforwardly use the USB ID to determine if a device needs special treatment... but in the case of ID 0x174c:0x55aa, ASMedia has reused the same ID for different chipsets with different levels of support for UAS. So the uas_use_uas_driver() function has to check for specific attributes of the device in order to try to determine which chipset is actually in use, and then based on that decide whether to use the uas driver for that device. Unfortunately when this happens there aren't any kernel messages generated to explicitly state what it has decided.

(Presumably one could use the output of "lsusb -v -d174c:55aa" in combination with the comments in the uas_use_uas_driver() function to determine what was happening with a particular device, and why.... But in any case, note that the detection logic does not look at the Product string [e.g. "ASMT1053"] that gets printed as part of the dmesg lines when the device is plugged in -- that name doesn't actually tell you anything about what the uas-detection logic will decide about that particular device.)

Nathan
  • 161
  • 2