STICKY: If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this

[jdb]

We have seen reports of extremely degraded performance when using several types of USB3.0 to SSD adapter or when using native USB3.0 disk drives. This post details why there is a difference in behaviour from models prior to Pi 4 and the recommended workaround.

Prior to Pi 4, the USB host controller software did not support DMA scatter-gather operations. As a result of this limitation, the USB Attached SCSI (UAS) driver was not enabled. With Pi 4, as the xHCI driver does support scatter-gather and to get the most performance out of a USB3.0 attached SSD/disk we enabled UAS by default.

UAS is an upgraded transport protocol compared to USB mass-storage - commands and data are separated into different queues and multiple outstanding commands can be in flight at the same time, as opposed to USB mass-storage's lock-step relationship between commands and data. This allows better saturation of the 4GBps USB3.0 transport as there can be a continuous stream of data to and from a device.

It's very rare to see a UAS enabled USB2.0 device. Almost all USB3.0 devices on the market today are UAS-capable. It should be noted that if you plug a USB3.0 UAS device into a USB2.0 port on the Pi 4, the UAS driver will still be used - but at a slower top speed.

UAS is wonderful, until you come across UAS devices that don't fully implement the UAS specification. Typically, these devices will just stop responding when issued UAS commands that they don't like, or may in rare cases throw write data away which can cause filesystem corruption.

The Linux kernel has a built-in blacklist for devices known to be unreliable when using UAS. This is not an exhaustive list - if a manufacturer releases a new version of a controller with a different product ID, the blacklist will no longer match.

The most common symptoms of a misbehaving UAS device are
- Extremely slow performance - in the kilobytes per second range
- Frequent disconnects-reconnects of the device with the desktop repeatedly displaying the "removable medium inserted" dialogue box
- The kernel message log (dmesg) reports errors relating to a UAS device that look like this:

Code: Select all

[ 501.594683] usbcore: registered new interface driver usb-storage
[ 501.599729] scsi host6: uas
[ 501.599800] usbcore: registered new interface driver uas
...
[ 573.203294] sd 6:0:0:0: [sda] tag#29 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[ 573.203302] sd 6:0:0:0: [sda] tag#29 CDB: Write(10) 2a 00 00 4f a0 00 00 04 00 00
[ 573.205063] sd 6:0:0:0: [sda] tag#28 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
[ 573.205070] sd 6:0:0:0: [sda] tag#28 CDB: Write(10) 2a 00 00 4f a4 00 00 04 00 00
[ 573.208537] sd 6:0:0:0: [sda] tag#27 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
...
[ 573.269992] scsi host6: uas_eh_device_reset_handler start
[ 573.393710] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 573.414256] scsi host6: uas_eh_device_reset_handler success

These errors may also appear due to poor power quality or overloading the Pi's maximum 1.2A downstream USB port current, but if they persist when using a powered hub then they are genuine UAS issues.

All UAS drives must support mass-storage as a fallback option. The kernel can be told to ignore the UAS interface of a device and just use mass-storage - the usb-storage driver has a "quirks" option for this purpose. As UAS is built-in to the kernel to allow the root filesystem to be installed on an SSD, the quirk needs to go into cmdline.txt as a module parameter. This parameter matches the USB Vendor ID (vid), Product ID (pid) and overlays the specified quirks that disable specific features for this device.

1. Finding the VID and PID of your USB SSD
Disconnect the USB SSD. In a terminal window, run the command sudo dmesg -C.
Now, plug in the SSD and run dmesg with no parameters.
You should get output that looks like this:

Code: Select all

[ 4096.609817] usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[ 4096.646369] usb 2-1: New USB device found, idVendor=2109, idProduct=0715, bcdDevice=a0.00
[ 4096.646385] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4096.646397] usb 2-1: Product: SABRENT
[ 4096.646409] usb 2-1: Manufacturer: SABRENT
[ 4096.646421] usb 2-1: SerialNumber: 000000123AD2
[ 4096.655154] scsi host0: uas
[ 4096.669178] scsi 0:0:0:0: Direct-Access              SABRENT          2210 PQ: 0 ANSI: 6
[ 4096.670993] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 4096.673710] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)

The idVendor and idProduct are the two hexadecimal numbers you need to take a note of.

1a. Multiple SSDs
If you have multiple USB SSD devices plugged into a single Pi 4, then for each device experiencing issues repeat Step 1 above and make a note of each idVendor and idProduct pair.

2. Add the quirks to /boot/cmdline.txt
Run a text editor as root - sudo nano /boot/cmdline.txt from the console or sudo leafpad /boot/cmdline.txt from the desktop.
At the start of the line of parameters, add the text usb-storage.quirks=aaaa:bbbb:u where aaaa is the idVendor for your device and bbbb is the idProduct. So, with the device above the string will be usb-storage.quirks=2109:0715:u.

cmdline.png (21.45 KiB) Viewed 395535 times

For multiple devices with different VID:PID pairs, expand the parameter with a comma between each vid:pid:u triplet like this: usb-storage.quirks=0123:4567:u,2109:0715:u.

Save the file and exit the editor.

3. Reboot.

4. Check that it worked
To check that the quirk has been applied successfully, run dmesg | grep usb-storage and check that the VID and PID is listed as having a quirk applied:

Code: Select all

[    2.495725] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[    2.512739] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[    2.531823] usb-storage 2-1:1.0: USB Mass Storage device detected
[    2.549642] usb-storage 2-1:1.0: Quirks match for vid 2109 pid 0715: 800000
[    2.566177] scsi host0: usb-storage 2-1:1.0

Typically, most drives are still performant with usb-storage. They may not be able to saturate a USB3.0 connection but should still get 150-200MB/s under most workloads.

[gkreidl]

Thanks. This should be a sticky.

[jamesh]

Thanks. This should be a sticky.

It is now.

If people has a specific comment on this post, feel free to post it, but if you have an issue with a USB3 drive that is not fixed by the information in this post, please start a new thread to avoid polluting this one. Posts that distract from this information will be deleted without warning.

[drgeoff]

Maybe the "At the start of the line of parameters," in step 2 could be more explicit about what that line looks like.

[jdb]

Or perhaps a screenshot will suffice.

[DarkPlatinum]

What are "normal" SSD speeds supposed to be like?

[goodburner]

Thanks, before I did this I was waiting for 5 mins for Raspy 4B to boot, it was stuck after "Reached Target sound card", Chromium took 2-3 minutes to load the first time.

Buffered read speeds were incredibly slow,

Timing buffered disk reads 30 MB/sec

After I added usb-storage.quirks=174c:55aa:u and rebooted the issues got resolved.

Here's my cable and SSD for reference,

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

SSD is just a Western Digital 120 GB internal.


Also, the other USB 3.0 is completely non-functional if I do this. Any fixes?

[jdb]

What are "normal" SSD speeds supposed to be like?

As fast as the SSD can go, or 350MB/s - whichever is lower.

Thanks, before I did this I was waiting for 5 mins for Raspy 4B to boot, it was stuck after "Reached Target sound card", Chromium took 2-3 minutes to load the first time.

Buffered read speeds were incredibly slow,

Timing buffered disk reads 30 MB/sec

After I added usb-storage.quirks=174c:55aa:u and rebooted the issues got resolved.

Here's my cable and SSD for reference,

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

SSD is just a Western Digital 120 GB internal.


Also, the other USB 3.0 is completely non-functional if I do this. Any fixes?

Define "other USB3.0". Do you have two USB3.0 devices plugged in, or is one of the ports on the Pi 4 non functional?

[goodburner]

What are "normal" SSD speeds supposed to be like?

As fast as the SSD can go, or 350MB/s - whichever is lower.

Thanks, before I did this I was waiting for 5 mins for Raspy 4B to boot, it was stuck after "Reached Target sound card", Chromium took 2-3 minutes to load the first time.

Buffered read speeds were incredibly slow,

Timing buffered disk reads 30 MB/sec

After I added usb-storage.quirks=174c:55aa:u and rebooted the issues got resolved.

Here's my cable and SSD for reference,

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

SSD is just a Western Digital 120 GB internal.


Also, the other USB 3.0 is completely non-functional if I do this. Any fixes?

Define "other USB3.0". Do you have two USB3.0 devices plugged in, or is one of the ports on the Pi 4 non functional?

if I plug in a remote 2.4ghz receiver for keyboard/mouse or even a microcontroller without any peripherals it doesn't provide any power to it. the receiver doesn't detect mouse/kb movements and the mcu is not being provided any power.

if I plug them into a usb 2.0 port it works.

[jerrm]

USB 3 drive support in Linux is a mess. Compounded by the fact that many manufacturers change underlying chipsets without changing part numbers. The adapter bought last month may not be the same as the same part number bought today.

The foundation ought to look at an official Pi adapter or Pi Certification for adapters that reliably offer unthrottled, no quirks needed, UASP support.

[goodburner]

I don't know what changed, but I upgraded to the latest bootloader and kernel and I'm now able to simultaneously interact with all 4 USB devices, one SSD, two Microcontrollers and a wireless receiver for mouse/kb.

I'll look up the change notes if we have them.

[davidcoton]

I don't know what changed, but I upgraded to the latest bootloader and kernel...

Isn't it obvious what changed? The bootloader (probably irrelevant) and the kernel

[HankB]

I ran into this using a Crucial M4 SSD (ancient in computer years ) with a USB3 enclosure. It worked on USB2 but Raspbian did not even create the /dev entry when connected to a USB3 port. Applying the fix seens to have resolved this - Thanks!
Now my questions... It seems that the problem is with the SSD itself and the fix blacklists the USB3/SATA adapter, right? That means that if I use a different adapter for this SSD I will need to change the vendor:device ID in /boot/cmdline.txt. Likewise if I connect a different SSD to this adapter, I may be able to eliminate this work around if the drive provides better UAS support. Do I have this right?
Do we have any idea if this will have any implications with USB boot when that becomes available or is it going to be unrelated? lsusb identifies this device as

Code: Select all

Bus 002 Device 002: ID 357d:7788 Sharkoon QuickPort XT

Thanks!

[jerrm]

Now my questions... It seems that the problem is with the SSD itself and the fix blacklists the USB3/SATA adapter, right? That means that if I use a different adapter for this SSD I will need to change the vendor:device ID in /boot/cmdline.txt. Likewise if I connect a different SSD to this adapter, I may be able to eliminate this work around if the drive provides better UAS support. Do I have this right?

I think you have it backwards. The problem is the USB adapter, not the drive itself.

[HankB]

Now my questions... It seems that the problem is with the SSD itself and the fix blacklists the USB3/SATA adapter, right? That means that if I use a different adapter for this SSD I will need to change the vendor:device ID in /boot/cmdline.txt. Likewise if I connect a different SSD to this adapter, I may be able to eliminate this work around if the drive provides better UAS support. Do I have this right?

I think you have it backwards. The problem is the USB adapter, not the drive itself.

Thanks for putting me right. (Don;t be shy about saying "I'm sure you're wrong" if that's the case. I'd rather be wrong than uncertain. )

[superchomp]

Tried the steps above (after inserting a powered usb 3 hub into the equation).
Sabrent USB 3.0 2.5" drive enclosure idVendor=152d, idProduct=1561, bcdDevice= 2.04 with a Samsung EVO 850 500GB.
-speeds before switching to usb-storage: 34MB/s speeds after: 44MB/s
Seagate 4TB Backup Plus 2.5" USB 3.0 idVendor=0bc2, idProduct=ab30, bcdDevice= 1.09
-speeds before switching to usb-storage: 35MB/s speeds after: 27MB/s

Those are speeds over gigabit ethernet using Samba / NTFS.

Speeds directly connected to a Win10 box: 450MB/s (Sabrent w/ Samsung), and 120MB/s (Seagate 4TB BUP).

So, my plan for RPi 4 as a NAS seems to be bottlenecked by USB 3 on Raspbian.

EDIT: Solved. The quirks work and the SSD gets 333MB/sec and the Seagate 4TB 140MB/sec.
If you want to use this with Samba, make sure the drives are formatted EXT4. Over the network I'm getting 105MB/sec to USB3 drives connected to a hub on the Pi4.

[flyingsquirrelarmy]

Tried the steps above (after inserting a powered usb 3 hub into the equation).
Sabrent USB 3.0 2.5" drive enclosure idVendor=152d, idProduct=1561, bcdDevice= 2.04 with a Samsung EVO 850 500GB.
-speeds before switching to usb-storage: 34MB/s speeds after: 44MB/s
Seagate 4TB Backup Plus 2.5" USB 3.0 idVendor=0bc2, idProduct=ab30, bcdDevice= 1.09
-speeds before switching to usb-storage: 35MB/s speeds after: 27MB/s

Those are speeds over gigabit ethernet using Samba / NTFS.

Speeds directly connected to a Win10 box: 450MB/s (Sabrent w/ Samsung), and 120MB/s (Seagate 4TB BUP).

So, my plan for RPi 4 as a NAS seems to be bottlenecked by USB 3 on Raspbian.

I just did this with the same Sabrent USB and a Samung 850 EVO and got 344.58 MB/sec

[Herbaldew]

I seem to have a mouse problem after applying this.

I also have a Sabrent idVendor=152d, idProduct=1561 but with an old 60GB OCZ SSD.

I didn't record my speeds, but the bottom number was ~30 on USB2 and jumped to ~260 on USB3 after applying the quirk.

However, my Logitech wireless mouse will not work plugged into either USB port while the Sabrent is plugged in to the USB3 port.

[gkreidl]

I seem to have a mouse problem after applying this.

I also have a Sabrent idVendor=152d, idProduct=1561 but with an old 60GB OCZ SSD.

I didn't record my speeds, but the bottom number was ~30 on USB2 and jumped to ~260 on USB3 after applying the quirk.

However, my Logitech wireless mouse will not work plugged into either USB port while the Sabrent is plugged in to the USB3 port.

Use an USB extension cable for the wirelss mouse dongle.

[Herbaldew]

Use an USB extension cable for the wirelss mouse dongle.

Thanks. Ugly, but it works.

[jerrm]

Has any anyone found a USB3 to SATA adapter for the Pi4 that works with UASP and TRIM support?

I had assumed the UAS issues mentioned here were of the normal Linux variety, but at least part of it appears Pi4 specific.

My go to adapter (JMS578 based) for Linux works great under PC Debian Buster (and other PC Linux distros).

It fails horribly on the Pi4. A simple bonnie++ benchmark stalls out completely, never finishes and floods the logs.

The adapter works on the Pi 4 with UAS disabled, but that has never been necessary with this adapter under PC Linux. (and under high loads - 30+ GBs, thousands of files nightly). No UAS also means no TRIM.

[ferofero33]

I had that issue with Seagate Backup Hub 8TB USB drive - getting ~0.5-2 MB/s in hdparm speed test.
It was strange, because that Seagate drive has also USB hub with 2x USB3 ports and Seagate 2.5"" 5TB drive connected to that USB port was able to reach ~130MB/s.
After applying this patch I'm getting ~190 MB/s from 8TB drive.

THANKS.

After applying the quirks option for Seagate Backu Hub 8TB drive I realised, that 2.5" 5TB drive connected to USB hub has same problem.
With applied quirks setting, both drives work OK.

[DaReaLDeviL]

Is it possible to deactivate UAS by general and what would be the command?

[rayrayrayraydog]

I'd like to reiterate the question asked above -- are there any *known good* UASP supported USB3.0<>SATA adapters for the Pi 4? I've tried two versions (USB-C and USB3) of this cheap Orico enclosure from Amazon and they both have the problem described here. https://www.amazon.com/gp/product/B01LY97QE8/ I would buy a different one if it was documented that it works properly with the Pi 4, but otherwise I'm sure the issue will be resolved in future updates.

[HankB]

I'd like to reiterate the question asked above -- are there any *known good* UASP supported USB3.0<>SATA adapters for the Pi 4?

I'm using the one in this post. It works fine with with my Pi 4B. https://www.raspberrypi.org/forums/view ... 7#p1503225 I would have preferred an enclosure rather than an adapter cable but the adapter fits the SSD firmly so there is no issue with it falling off.

I had used an Orico enclosure with the work around (disable UAS) and benchmarked both. Random read/write performance is a little better with UAS enabled.