How to Fix Unreliable USB Hard Drives, Stalled Transfers in Linux

Last June, I reviewed a Ryzen Embedded SBC with Windows 10, and the USB hard drive I normally use for review had all sorts of problems including very slow speeds and/or stalled transfers but no error messages.

Last week, I tried again by installing Ubuntu 20.04 on the same Ryzen Embedded SBC, and the USB hard drive had troubles again, so just assume there were some hardware incompatibility issues between the SBC and the drive, and there may not be a fix or workaround.

Sometimes, it’s indeed a hardware issue with the drive getting too many bad blocks, and if that’s the case, and the drive is still under warranty you can return it and get a fresh new (or refurbished) drive for free. But that drive was still working with my laptop getting around 100MB/s.

So I ran out of ideas until numero53 commented he had similar problems with many USB-SATA adapters, and the trick was to disable UAS (USB Attached SCSI) which in theory you’d want to improve performance. The problem was reported by Raspberry Pi and ODROID users, and you’d normally get error messages that look like that:

Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#29 uas_eh_abort_handler 0 uas-tag 30 inflight: CMD IN 
Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#29 CDB: opcode=0x88 88 00 00 00 00 01 5c 00 13 f8 00 00 00 08 00 00
Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#28 uas_eh_abort_handler 0 uas-tag 29 inflight: CMD IN 
Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#28 CDB: opcode=0x88 88 00 00 00 00 01 5c 00 13 f0 00 00 00 08 00 00
Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD IN 
Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#27 CDB: opcode=0x88 88 00 00 00 00 01 5c 00 13 e8 00 00 00 08 00 00

Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#29 uas_eh_abort_handler 0 uas-tag 30 inflight: CMD IN

Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#29 CDB: opcode=0x88 88 00 00 00 00 01 5c 00 13 f8 00 00 00 08 00 00

Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#28 uas_eh_abort_handler 0 uas-tag 29 inflight: CMD IN

Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#28 CDB: opcode=0x88 88 00 00 00 00 01 5c 00 13 f0 00 00 00 08 00 00

Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD IN

Jun 16 04:59:18 feynman kernel: sd 1:0:0:0: [sdb] tag#27 CDB: opcode=0x88 88 00 00 00 00 01 5c 00 13 e8 00 00 00 08 00 00

I did not have any such messages, but I still tried to disable UAS on this particular drive with little conviction it would work. First, we’ll need to find the USB VID/PID for the adapter:

lsusb | grep Seagate
Bus 002 Device 004: ID 0bc2:2312 Seagate RSS LLC

1 2	lsusb \| grep Seagate Bus 002 Device 004: ID 0bc2:2312 Seagate RSS LLC

Now we can create a file to blacklist the drive/adapter in order to prevent the UAS module to load for this drive:

echo options usb-storage quirks=0bc2:2312:u | sudo tee /etc/modprobe.d/blacklist_uas_0bc2.conf
sudo update-initramfs -u

1 2	echo options usb-storage quirks=0bc2:2312:u \| sudo tee /etc/modprobe.d/blacklist_uas_0bc2.conf sudo update-initramfs -u

After a reboot, we can see the drive was blacklisted:

dmesg | grep -i uas
[    0.425573] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.975254] usbcore: registered new interface driver uas
[    2.271540] usb 2-2.4: UAS is blacklisted for this device, using usb-storage instead

dmesg | grep -i uas

[ 0.425573] squashfs: version 4.0 (2009/01/31) Phillip Lougher

[ 1.975254] usbcore: registered new interface driver uas

[ 2.271540] usb 2-2.4: UAS is blacklisted for this device, using usb-storage instead

Let’s see if that fixed my issue by running iozone storage benchmark:

iozone -e -I -a -s 1000M -r 1024k -r 16384k -i 0 -i 2

                                                               random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         1024000    1024    90423    91456                    2724687    78287                                                                
         1024000   16384    91281    98600                    1916998    92524                                                                

iozone test complete.

iozone -e -I -a -s 1000M -r 1024k -r 16384k -i 0 -i 2

random random bkwd record stride

kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread

1024000 1024 90423 91456 2724687 78287

1024000 16384 91281 98600 1916998 92524

iozone test complete.

It could write a 1GB file at about 90+MB/s. Pretty much normal on this drive. Issue fixed! The ~2GB/s read numbers are clearly influenced by the cache…

It’s apparently quite a common problem with Seagate (VID: 0x0bc2) and Western Digital (VID: 0x1058) USB drives, and Thomas Kaiser just blacklisted all such drives in Armbian by default a few years ago.

OK, so we’ve found a workaround in Linux/Ubuntu. But what about Windows 10, since I got the same problem here. There’s no obvious solution that I could find. There’s uaspstor.sys file in the %WinDir%\System32\drivers folder that is the USB Attached SCSI (UAS) Driver for Windows 10. But it’s not used directly by my drive.

Seagate Expansion Windows 10 Driver — Click to Enlarge

I suppose it might be possible to try to move/rename drivers’ files until the issue is solved, but it’s not ideal since other drives that actually work properly with UAS would also be affected. I looked for methods to blacklist UAS for specific drivers in Windows 10 just like we just did in Linux, but there doesn’t seem to be any solution. If you do have a workaround, please do share.

Jean-Luc Aufranc (CNXSoft)

Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.