30

On Ubuntu 15.10, when I want to format using the NTFS file system an external 4TO disk connected by USB3 (on a StarTech USB/eSATA hard disk dock), I have a lot of I/O errors, and the format fails.

I tried GParted v 0.19, and GParted on the latest live CD gparted-live-0.23.0-1-i586.iso, with the same problem.

After that, and using GParted on Ubuntu 15.10 and the same USB3 connection, I tried to format as ext4, without problems. It's really strange.

Because I don't know if the mkfs.ext4 tools used by GParted to format the disk test the disk like (or not like) mkntfs, I first suppose that the problem is linked to the new disk. Perhaps this new disk is causing problems. So I try running e2fsck -c on this HDD. On Ubuntu 15.10, e2fsck -c freezes at 0.45%, and I don't know why.

So, using another version of Ubuntu (15.04) on the same PC, I try to connect the same 4TO disk using the eSATA connection of the StarTech HDD dock. This time, e2fsck -c runs correctly.

After some hours, you can see the result:

sudo e2fsck -c /dev/sdc1
e2fsck 1.42.12 (29-Aug-2014)
ColdCase : récupération du journal
Vérification des blocs défectueux (test en mode lecture seule) : complété                                             
ColdCase: Updating bad block inode.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe

ColdCase: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
ColdCase : 11/244195328 fichiers (0.0% non contigus), 15377150/976754176 blocs

I'm not an expert in badblock outputs, but it seems there is no bad block at all on this disk?

So, if the problem is not the hard drive, maybe the problem can be linked to mkntfs used over USB3? What other tests can I try?

Some information about the USB dock:

➜  ~  lsusb
...
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
...


➜  ~  sudo lsusb -v -d 174c:55aa
Mot de passe [sudo] pour reyman : 

Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x174c ASMedia Technology Inc.
  idProduct          0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
  bcdDevice            1.00
  iManufacturer           2 asmedia
  iProduct                3 ASM1053E
  iSerial                 1 123456789012
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          121
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower               36mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             16
        Data-in pipe (0x03)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             16
        Data-out pipe (0x04)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             16
        Status pipe (0x02)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        Command pipe (0x01)
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
Device Status:     0x0001
  Self Powered

Information about the disk in question: /dev/sdd

➜  ~  sudo fdisk -l /dev/sdd
Disque /dev/sdd : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: ACD5760B-2898-435E-82C6-CB3119758C9B

Périphérique Start        Fin   Secteurs  Size Type
/dev/sdd1     2048 7814035455 7814033408  3,7T Linux filesystem

dmesg returns a lot of errors about the disk; see this extract:

[   68.856381] scsi host6: uas_eh_bus_reset_handler start
[   68.968376] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd
[   68.989825] scsi host6: uas_eh_bus_reset_handler success
[   99.881608] sd 6:0:0:0: [sdd] tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT 
[   99.881618] sd 6:0:0:0: [sdd] tag#12 CDB: Write(16) 8a 00 00 00 00 00 e8 c4 08 00 00 00 00 08 00 00
[   99.881856] sd 6:0:0:0: [sdd] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT 
[   99.881861] sd 6:0:0:0: [sdd] tag#5 CDB: Write(16) 8a 00 00 00 00 00 cd 01 08 f0 00 00 00 10 00 00
[   99.881967] sd 6:0:0:0: [sdd] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT 
[   99.881972] sd 6:0:0:0: [sdd] tag#4 CDB: Write(16) 8a 00 00 00 00 00 cd 01 08 00 00 00 00 f0 00 00
[   99.882085] sd 6:0:0:0: [sdd] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT 
[   99.882090] sd 6:0:0:0: [sdd] tag#3 CDB: Write(16) 8a 00 00 00 00 00 cd 01 07 10 00 00 00 f0 00 00
[   99.882171] sd 6:0:0:0: [sdd] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT 
[   99.882175] sd 6:0:0:0: [sdd] tag#2 CDB: Write(16) 8a 00 00 00 00 00 cd 01 06 20 00 00 00 f0 00 00
[   99.882255] sd 6:0:0:0: [sdd] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT 
[   99.882258] sd 6:0:0:0: [sdd] tag#1 CDB: Write(16) 8a 00 00 00 00 00 cd 01 05 30 00 00 00 f0 00 00
[   99.882338] sd 6:0:0:0: [sdd] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT 
[   99.882342] sd 6:0:0:0: [sdd] tag#0 CDB: Write(16) 8a 00 00 00 00 00 cd 01 04 40 00 00 00 f0 00 00
[   99.882419] sd 6:0:0:0: [sdd] tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT 
[   99.882423] sd 6:0:0:0: [sdd] tag#11 CDB: Write(16) 8a 00 00 00 00 00 cd 00 f9 00 00 00 00 f0 00 00
[   99.882480] sd 6:0:0:0: [sdd] tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT 
[   99.882483] sd 6:0:0:0: [sdd] tag#10 CDB: Write(16) 8a 00 00 00 00 00 cd 00 f9 f0 00 00 00 f0 00 00
[   99.882530] sd 6:0:0:0: [sdd] tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT 
[   99.882532] sd 6:0:0:0: [sdd] tag#9 CDB: Write(16) 8a 00 00 00 00 00 cd 00 fa e0 00 00 00 f0 00 00
[   99.882593] sd 6:0:0:0: [sdd] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD 
[   99.882596] sd 6:0:0:0: [sdd] tag#8 CDB: Write(16) 8a 00 00 00 00 00 cd 00 fb d0 00 00 00 f0 00 00
[   99.882667] scsi host6: uas_eh_bus_reset_handler start
[   99.994700] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd
[  100.015613] scsi host6: uas_eh_bus_reset_handler success
[  135.962175] sd 6:0:0:0: [sdd] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT 
[  135.962185] sd 6:0:0:0: [sdd] tag#5 CDB: Write(16) 8a 00 00 00 00 00 cd 40 78 f0 00 00 00 10 00 00
[  135.962428] sd 6:0:0:0: [sdd] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT 
[  135.962436] sd 6:0:0:0: [sdd] tag#4 CDB: Write(16) 8a 00 00 00 00 00 cd 40 78 00 00 00 00 f0 00 00
[  135.962567] sd 6:0:0:0: [sdd] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT 
[  135.962576] sd 6:0:0:0: [sdd] tag#3 CDB: Write(16) 8a 00 00 00 00 00 cd 40 77 10 00 00 00 f0 00 00
[  135.962682] sd 6:0:0:0: [sdd] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT 
[  135.962690] sd 6:0:0:0: [sdd] tag#2 CDB: Write(16) 8a 00 00 00 00 00 cd 40 76 20 00 00 00 f0 00 00
[  135.962822] sd 6:0:0:0: [sdd] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD 
[  135.962830] sd 6:0:0:0: [sdd] tag#1 CDB: Write(16) 8a 00 00 00 00 00 cd 40 75 30 00 00 00 f0 00 00
[  160.904916] sd 6:0:0:0: [sdd] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT 
[  160.904926] sd 6:0:0:0: [sdd] tag#0 CDB: Write(16) 8a 00 00 00 00 00 00 00 29 08 00 00 00 08 00 00
[  160.905068] scsi host6: uas_eh_bus_reset_handler start

I found this information on this forum post, that there is some problem with UAS and new Linux kernels? It seems the problem is known in many places on the internet, USB3 + Linux seems problematic in many cases -- but for old kernels. Any ideas to resolve this problem on a more recent kernel?

My kernel is:

➜  ~  uname -r 
4.2.0-16-generic

Hmm, it seems UAS is broken for different USB3 chips of ASMedia Technology Inc.; you can see more information here.

I suppose this is my problem, but how can I resolve it now, and which chip is used for the USB3 implementation in the StarTech dock?

3 Answers 3

27

I had this same issue on Mint 18, but the solution I found can probably be applied to *Ubuntu 15/16 as well as similar Linux distributions. For me, however, I was getting an irrecoverable system lockup soon after seeing the UAS errors in dmesg.

My enclosure has an ASMedia ASM1053 chip, which seems to have issues with the UAS module of my kernel (4.4.0-72-generic).

After a bit of searching, I combined two solutions I found: this one, which YtvwlD mentioned and this one.

First, you must get the hardware ID of your device using the lsusb command. Once you do that, locate your external/enclosure/bridge. It might show up like below:

Bus 002 Device 002: ID 174c:5136 ASMedia Technology Inc. ASM1053 SATA 6Gb/s bridge

In my case, the ID is 174c:5136.

After that, you must create a file in /etc/modprobe.d/ so the proper device is blacklisted from using UAS (which is causing issues), update the initramfs image using update-initramfs, then reboot for the change to take effect.

$ echo options usb-storage quirks=174c:5136:u | sudo tee /etc/modprobe.d/blacklist_uas.conf
$ sudo update-initramfs -u
$ sudo reboot

Of course, replace "174c:5136" with the hardware ID of your bridge/enclosure/external. If done correctly, you should see a message like this from dmesg when you connect your device after rebooting:

[   93.985002] usb 4-1: UAS is blacklisted for this device, using usb-storage instead

I haven't had any issues with my enclosure since.

6
  • 1
    Looks like I'm also running into this problem in Debian 9.4 4.14.18-sunxi64. :(
    – TCB13
    May 3, 2018 at 15:13
  • Fixed the issue in my kernel here: unix.stackexchange.com/a/441772/23085. Looks like some kernels have usb-storage built-in instead of loaded as a module and the procedure is a little bit different.
    – TCB13
    May 4, 2018 at 12:30
  • 2
    While this performance-reducing, hideous hack, applied to every machine, does allow the enclosure to basically work, it is still a performance-reducing, hideous hack, that must be applied to every machine. What if I boot a Linux live distro, expecting to be able to backup or recover files? This hack won't work there. So whom should I report this problem to? Should I report it as a Linux kernel bug? Should I leave a negative review of the enclosure, that was advertised as Linux-compatible? Whose fault is this problem?
    – Boann
    Sep 29, 2018 at 15:07
  • 1
    worked for me with the: 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
    – Dr. Tyrell
    Dec 17, 2018 at 22:37
  • 2
    @Boann any device that kernel tries to use with UAS protocol that does not work correctly is technically a broken hardware. The hardware should not advertise UAS support unless it really works. You still can report this to Linux kernel usb subsystem maintainers that have a list of known-bad hardware that can still be used if handled specially. You can also opt-in to various workarounds using quirks parameter of usb_storage module - exactly the same thing will be activated automatically if kernel developers know about the issue. The performance will still be reduced and/or features missing. Jan 1, 2019 at 21:52
16

I ran into this issue today on a 4.8.0 kernel.

According to this forum post it can be circumvented by

$ echo options usb-storage quirks=357d:7788:u | sudo tee /etc/modprobe.d/blacklist_uas_357d.conf
$ sudo update-initramfs -u

and rebooting.

1
  • 11
    Note that the quirks parameter needs to be set to the particular ID of the offending device, found via lsusb.
    – Boann
    Sep 29, 2018 at 15:24
7

In order to apply the quirk mentioned by other answers on the fly, you can also set it at runtime:

echo "152d:0583:u" | sudo tee /sys/module/usb_storage/parameters/quirks

Replace 152d:0583 with the USB device ID of your device, of course.

This will set the quirks parameter of the usb-storage module to the aforementioned value without requiring a reboot.

3
  • 1
    Couldn't get my raspberry pi 4 to take a /etc/modprobe.d/blacklist_uas.conf hack (@Cinos Modnar answer) into account, so I ended using your solution in /etc/rc.local. So far it's working!
    – Laurent'
    Oct 15, 2020 at 9:07
  • It worked for me. Is this just a different way of doing this instead of doing the /etc/modprobe.d/blacklist_uas.conf, or do I have to do this for every new boot? Oct 20, 2020 at 6:41
  • 1
    Would it not be better to use tee with the -a flag to not accidentally overwrite data if quirks already contains some?
    – lcnittl
    Dec 6, 2020 at 11:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .