ebin-dev
Posts: 4
Joined: Fri Nov 22, 2019 1:03 pm

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

Fri Nov 22, 2019 1:44 pm

Thanks for the valuable information.

I have tested serveral usb3.0 - sata adapters attached to a Pi 4B 4GB: the four adapters using the JMicron JMS578 Chip all work just fine without usb storage-quirks - but I had to flash the firmware to version v00.04.01.04 as provided in the odroid forum ( https://wiki.odroid.com/odroid-xu4/soft ... _fw_update ).

Edit: a spare OCZ Vertex 2 was used for the test.

The bridge is detected as JMS567 and uas is active:

Code: Select all

# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

The system boots the Pi4 flawlessly from an SD card with the root partition on the USB 3.0 drive as described here https://jamesachambers.com/raspberry-pi ... sh-drives/ ; speed tests are promising:

Code: Select all

# sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.21838 s, 206 MB/s
# dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.55523 s, 690 MB/s
# sudo /sbin/sysctl -w vm.drop_caches=3
vm.drop_caches = 3
# dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.20861 s, 255 MB/s
# sudo hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   1756 MB in  2.00 seconds = 878.54 MB/sec
 Timing buffered disk reads: 704 MB in  3.01 seconds = 234.23 MB/sec
Please keep in mind that there are SSDs known to be problematic in this context, such as the Crucial MX100 - it did not work when attached to the USB3.0 port neither through an JMS578 bridge nor through an ASM1153E bridge.
Last edited by ebin-dev on Mon Nov 25, 2019 5:16 pm, edited 2 times in total.

jerrm
Posts: 202
Joined: Wed May 02, 2018 7:35 pm

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

Fri Nov 22, 2019 11:08 pm

ebin-dev wrote:
Fri Nov 22, 2019 1:44 pm
I have tested serveral usb3.0 - sata adapters attached to a Pi 4B 4GB: the four adapters using the JMicron JMS578 Chip all work just fine without usb storage-quirks - but I had to flash the firmware to version v00.04.01.04 as provided in the odroid forum ( https://wiki.odroid.com/odroid-xu4/soft ... _fw_update ).
JMS578's still break for me with the odroid firmware. It mostly works - booting and hdparm benches look great - but can you complete a bonnie++ benchmark without errors in syslog?

ebin-dev
Posts: 4
Joined: Fri Nov 22, 2019 1:03 pm

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

Sat Nov 23, 2019 10:35 am

The bonnie++ benchmark was indeed entirely executed on the Pi 4B (4GB) without any error message in /var/log/syslog.

I have executed bonnie++ while the root partition was mounted from the USB 3.0 device using the JMicron JMS578 bridge. The firmware flashed to the bridge is NOT odroid specific but the standard firmware v.00.04.01.04 dated 2019.06.11 - downloadable though the odroid forum too.

Since my USB 3.0/sata bridges work anyway well under macOS 10.15 and Windows 10 (with any current SSD) I have to conclude that the issues with certain SSDs under Linux may arise due to lack of proper Linux USB3.0 support.

Hopefully the Raspberry Pi Foundation will solve those issues at least for a specific combination of USB3.0 bridges and current SSDs.

jerrm
Posts: 202
Joined: Wed May 02, 2018 7:35 pm

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

Sat Nov 23, 2019 6:56 pm

ebin-dev wrote:
Sat Nov 23, 2019 10:35 am
The bonnie++ benchmark was indeed entirely executed on the Pi 4B (4GB) without any error message in /var/log/syslog.
No luck here with that firmware and my three test dives. Two don't complete (with log errors), the third completes, but with a lot of spam in the logs.
ebin-dev wrote:
Sat Nov 23, 2019 10:35 am
Since my USB 3.0/sata bridges work anyway well under macOS 10.15 and Windows 10 (with any current SSD) I have to conclude that the issues with certain SSDs under Linux may arise due to lack of proper Linux USB3.0 support.
It's not Linux generically - JMS578 adapters work great with our Intel Linux PCs and notebooks. Maybe ARM or BCM or VL805 issues?

User avatar
rpdom
Posts: 16749
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

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

Sat Nov 23, 2019 8:01 pm

jerrm wrote:
Sat Nov 23, 2019 6:56 pm
It's not Linux generically - JMS578 adapters work great with our Intel Linux PCs and notebooks. Maybe ARM or BCM or VL805 issues?
One of my JMS578 adaptors doesn't work on my Intel Laptop using Debian. Lots of errors in dmesg. It works fine on my Pi 4B with quirks enabled.
Unreadable squiggle

ebin-dev
Posts: 4
Joined: Fri Nov 22, 2019 1:03 pm

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

Sun Nov 24, 2019 4:01 pm

I tried another spare SSD together with the Pi 4: a Samsung 840 EVO 250GB.

Using the JMS578 bridge with firmware v00.04.01.04 attached to the USB3.0 port and current 32bit kernel (4.19.75-v8+) the Samsung 840 EVO also works flawlessly without any errors, but only with storage-quirks (read and write > 200MB/s).

The SSD even works with the 64bit kernel (just append arm_64bit=1 to /boot/config.txt and reboot), but also only with storage-quirks (usb-storage.quirks=152d:0578:u). The read speed of the 64bit kernel is quite impressive if caches are not disabled (read 1.4GB/s):

64bit kernel - with storage quirks

Code: Select all

# uname -a
Linux grid 4.19.75-v8+ #1270 SMP PREEMPT Tue Sep 24 18:59:17 BST 2019 aarch64 GNU/Linux
# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
# sync; dd if=/dev/zero of=/mnt/ssd/tempfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.5732 s, 235 MB/s
# dd if=/mnt/ssd/tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.75015 s, 1.4 GB/s
# sudo /sbin/sysctl -w vm.drop_caches=3
vm.drop_caches = 3
# dd if=/mnt/ssd/tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.83441 s, 280 MB/s
# sudo hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   2010 MB in  2.00 seconds = 1005.91 MB/sec
 Timing buffered disk reads: 916 MB in  3.01 seconds = 304.78 MB/sec

32bit kernel - with storage quirks

Code: Select all

# uname -a
Linux grid 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux
# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
# sync; dd if=/dev/zero of=/mnt/ssd/tempfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.0284 s, 214 MB/s
# dd if=/mnt/ssd/tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.53998 s, 697 MB/s
# sudo /sbin/sysctl -w vm.drop_caches=3
vm.drop_caches = 3
# dd if=/mnt/ssd/tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.28262 s, 251 MB/s
# sudo hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   1728 MB in  2.00 seconds = 864.34 MB/sec
 Timing buffered disk reads: 928 MB in  3.00 seconds = 309.17 MB/sec

User avatar
ehem
Posts: 55
Joined: Mon Sep 09, 2019 1:17 am

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

Mon Nov 25, 2019 6:24 am

Has anyone tested devices with the JMicron JMS583 chip? When looking at mSATA and NVMe adapters I kept finding lots of them with this chip in them, but given JMicron's reputation.

pashar
Posts: 1
Joined: Wed Nov 27, 2019 4:53 pm

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

Wed Nov 27, 2019 5:14 pm

I have this problem with Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

however I can't figure out where to add quirks on Ubuntu 19.10

can somebody suggest?

-p

User avatar
SyncBerry
Posts: 71
Joined: Sat Sep 21, 2019 11:13 am
Location: France (S-W)

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

Wed Nov 27, 2019 6:14 pm

Same place as others : /boot/cmdline.txt

sc0ttr
Posts: 1
Joined: Thu Nov 28, 2019 8:32 pm

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

Thu Nov 28, 2019 9:01 pm

Hi, I tried with the silverstone MS11 and and intel 660p 2Tb. It works fine in ubunt on x86 and windows. However on RPI4, it is just not recognised. I tried with quirks enabled, but still no joy. If anyone has any hints, that would be warmly appreciated

charithaka
Posts: 6
Joined: Mon Apr 17, 2017 7:45 am

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

Mon Dec 09, 2019 4:03 pm

Hi anyone know how to apply this patch on ubuntu ?. I was testing bcache on ubuntu and due to this error my SSD cache was unusable. Raspbian not working with bcache as I cannot find or load bcache kernel module

ghosty627
Posts: 1
Joined: Tue Dec 10, 2019 12:37 pm

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

Tue Dec 10, 2019 3:39 pm

Hihi, it dosn't work for me.
RPi4, 2x Sabrent USB 3.0 Adapter, 2x Samsung SSD 500GB 850 Evo.

Any ideas to help ?

Greetz :)

Sideeffect
Posts: 2
Joined: Mon Dec 02, 2019 1:44 am

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

Sun Dec 15, 2019 3:04 am

I bought a Fideco docking station which uses ASM1156 https://www.amazon.co.uk/Docking-Statio ... 146&sr=8-3. It works really well with UASP and I have had no issues with it and the pi 4. I then got a UGREEN USB C Hard Drive Enclosure which uses the ASM235CM chip. https://www.amazon.co.uk/UGREEN-Enclosu ... ers&sr=1-5. This suffers from write freezes when connected directly to the pi 4 however it runs perfectly when I connect it to the fideco USB 3.0 port which has it's own power source.

Both adapters are detected as ASM1051E and have the same VID and PID so I can't blacklist one without disabling UASP on both. So I am running both through the fideco.

I guess that my problem with freezes is due to lack of power from the Pi 4 USB port which is fixed when I use the self powered USB port from the Fideco.

User avatar
SyncBerry
Posts: 71
Joined: Sat Sep 21, 2019 11:13 am
Location: France (S-W)

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

Wed Dec 25, 2019 5:51 pm

PS : a reminder : the USB3 / SATA JMS578 enclosure I talked about above (ConnectLand branded) has a PCB inside which is marked "Atatech HD301 v1.8".
As the onboard led was far too blue shining although tiny 3V3 through 330ohm=1mA, I just cut it a leg with no bad side effect.

Mitschke
Posts: 4
Joined: Thu Dec 26, 2019 4:24 am

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

Thu Dec 26, 2019 4:31 am

I had no luck with JMS578 and an Intenso SSD. Only boots attached to an USB2 without quirks. Attached to an USB3 it only boots with quirks enabled. I tried the v00.04.01.04 Firmware and the most current Hardkernel version, either way no boot from sdcard/ssd root.

So no TRIM, which shouldn't be too much of a problem but still a little bit disappointing.

User avatar
SyncBerry
Posts: 71
Joined: Sat Sep 21, 2019 11:13 am
Location: France (S-W)

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

Fri Dec 27, 2019 3:48 pm

It won't boot OOTB even with the quirk. You'll also need to adapt /boot/cmdline.txt this way:

Code: Select all

usb-storage.quirks=152d:0578:u dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=8f4f4a26-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
And maybe also /etc/fstab (but this I'm not really sure)
Search the web for how to get your own PARTUUID to adapt the line above

Mitschke
Posts: 4
Joined: Thu Dec 26, 2019 4:24 am

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

Fri Dec 27, 2019 6:22 pm

Thank you, but as I alreaded stated, it boots, but only with quirks. Not without doing other configurations before, true, but still only with quirks. But since I finally got mymicro HDMI cable, I could watch the output, all other attempts were without a Monitor connected.

Neofito
Posts: 4
Joined: Wed Aug 30, 2017 11:18 pm

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

Sun Dec 29, 2019 3:23 pm

ebin-dev wrote:
Fri Nov 22, 2019 1:44 pm
Thanks for the valuable information.

I have tested serveral usb3.0 - sata adapters attached to a Pi 4B 4GB: the four adapters using the JMicron JMS578 Chip all work just fine without usb storage-quirks - but I had to flash the firmware to version v00.04.01.04 as provided in the odroid forum ( https://wiki.odroid.com/odroid-xu4/soft ... _fw_update ).

Edit: a spare OCZ Vertex 2 was used for the test.

The bridge is detected as JMS567 and uas is active:

Code: Select all

# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

The system boots the Pi4 flawlessly from an SD card with the root partition on the USB 3.0 drive as described here https://jamesachambers.com/raspberry-pi ... sh-drives/ ; speed tests are promising:

Code: Select all

# sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.21838 s, 206 MB/s
# dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.55523 s, 690 MB/s
# sudo /sbin/sysctl -w vm.drop_caches=3
vm.drop_caches = 3
# dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.20861 s, 255 MB/s
# sudo hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   1756 MB in  2.00 seconds = 878.54 MB/sec
 Timing buffered disk reads: 704 MB in  3.01 seconds = 234.23 MB/sec
Please keep in mind that there are SSDs known to be problematic in this context, such as the Crucial MX100 - it did not work when attached to the USB3.0 port neither through an JMS578 bridge nor through an ASM1153E bridge.
My MSATA to usb3 adapter is detected as JMS567, that means I could flash that firmware and get it work without quirk? Right now I had to activate quirk in order to be able to boot from usb3 (SD card with boot partition and root partition on the ssd).


Anyway thanks to the OP to post this fix, it helped a lot to me!!

User avatar
SyncBerry
Posts: 71
Joined: Sat Sep 21, 2019 11:13 am
Location: France (S-W)

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

Sun Dec 29, 2019 4:02 pm

Neofito wrote:
Sun Dec 29, 2019 3:23 pm
...
My MSATA to usb3 adapter is detected as JMS567...!!
Do have a close look at your own output of lsusb. Fortunately it may show
...Device 00X: ID 152d:0578 JMicron Tech ...
before the 567 description, like mine I flashed successfully

mattsch
Posts: 1
Joined: Sun Dec 29, 2019 7:39 pm

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

Sun Dec 29, 2019 7:48 pm

I have an ORICO transparent enclosure and thought everything worked fine. I did move my MariaDB data directory to the mounted disk and had an issue when booting up. MariaDB would always time out. I thought this was a MariaDB issue and fortunately found this topic when searching about another problem. Once I enabled quirks mode this issue was gone. Hope it helps someone who faces the same problem.

Kind of disappointing that lots of enclosures with UAS support don't actually work with UAS enabled.

Neofito
Posts: 4
Joined: Wed Aug 30, 2017 11:18 pm

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

Mon Dec 30, 2019 11:18 pm

SyncBerry wrote:
Sun Dec 29, 2019 4:02 pm
Neofito wrote:
Sun Dec 29, 2019 3:23 pm
...
My MSATA to usb3 adapter is detected as JMS567...!!
Do have a close look at your own output of lsusb. Fortunately it may show
...Device 00X: ID 152d:0578 JMicron Tech ...
before the 567 description, like mine I flashed successfully
this is my output

Code: Select all

[email protected]:~ $ lsusb
Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
I think we have the same :)

avraham
Posts: 1
Joined: Fri Jan 03, 2020 1:54 am

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

Fri Jan 03, 2020 2:20 am

superchomp wrote:
Sat Jul 27, 2019 5:06 pm
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.
How did you solve it?
I have the same enclosure but still get slow speeds after adding the quirks.

I'm using one drive in the enclosure for my root partition. Would that cause problems?

EDIT. Well, it looks like one of the of my USB 3.0 port was malfunctioning. I plugged my enclosure to the other USB 3.0 port and everything works great now.
Last edited by avraham on Mon Jan 13, 2020 5:24 am, edited 1 time in total.

Lipown
Posts: 88
Joined: Sun Oct 13, 2019 8:32 am

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

Fri Jan 10, 2020 3:54 pm

Guys, as I am now frustrated of this issue (https://www.raspberrypi.org/forums/view ... 8&t=261230), has anybody found the working UAS USB3/SATA convertor so you don't need this hack?

mcmanuf
Posts: 44
Joined: Wed Aug 22, 2012 12:29 am

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

Tue Jan 14, 2020 1:35 pm

I am having huge problems with transfer speed when using quirks.

I have made a very detailed post about it here:
https://www.raspberrypi.org/forums/view ... 8&t=261857

Instead of having more than 100 megabytes/s to usb3 drive it gets reduced to approx 22mb/s with quirk enabled.

This in contradiction to the first post where 150-200mb/s should be achieved.

xr8RGBNj
Posts: 2
Joined: Thu Jan 23, 2020 6:16 pm

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

Thu Jan 23, 2020 7:54 pm

I'm running Ubuntu 19.10, /boot/cmdline.txt doesn't exist and creating it with those options didn't successfully disable the feature. Here's what I did to get it working.

Get the Vendor and Product ID's

Code: Select all

lsusb -V
Apply the quirk

Code: Select all

echo options usb-storage quirks=VENDORID:PRODUCTID:u | sudo tee /etc/modprobe.d/blacklist_uas.conf
sudo update-initramfs -u
Reboot

Credit: https://unix.stackexchange.com/question ... er-problem

Return to “Troubleshooting”