Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USB3.0 to SATA adapter causes problems #3070

Closed
M-Reimer opened this issue Jul 12, 2019 · 68 comments
Closed

USB3.0 to SATA adapter causes problems #3070

M-Reimer opened this issue Jul 12, 2019 · 68 comments

Comments

@M-Reimer
Copy link

Describe the bug

I have a SATA SSD connected to a USB3.0 to SATA converter.

If I connect this to my Raspberry Pi 4, then the "Access" LED flashes pretty long and I get errors logged (uas_eh_device_reset_handler start)

To reproduce

This is the adapter:
https://www.amazon.de/dp/B079QQJB9L/

If this is used on the Raspberry Pi, it takes pretty long for the kernel to "detect" the SSD drive correctly. I haven't tested reliability while using the drive, so far.

I have tried a powered hub but the errors keep exactly the same.

System

Tried several systems. Up-to-date Raspbian and Arch Linux with several self-compiled kernels. Always the same problem.

Logs

Jul 12 20:38:34 alarmpi kernel: usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
Jul 12 20:38:34 alarmpi kernel: usb 2-1: New USB device found, idVendor=2109, idProduct=8110, bcdDevice=91.04
Jul 12 20:38:34 alarmpi kernel: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 12 20:38:34 alarmpi kernel: usb 2-1: Product: USB3.0 Hub
Jul 12 20:38:34 alarmpi kernel: usb 2-1: Manufacturer: VIA Labs, Inc.
Jul 12 20:38:34 alarmpi kernel: hub 2-1:1.0: USB hub found
Jul 12 20:38:34 alarmpi kernel: hub 2-1:1.0: 4 ports detected
Jul 12 20:38:34 alarmpi kernel: usb 2-1.1: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
Jul 12 20:38:34 alarmpi kernel: usb 2-1.1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=32.02
Jul 12 20:38:34 alarmpi kernel: usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 12 20:38:34 alarmpi kernel: usb 2-1.1: Product: JMS579
Jul 12 20:38:34 alarmpi kernel: usb 2-1.1: Manufacturer: JMicron
Jul 12 20:38:34 alarmpi kernel: usb 2-1.1: SerialNumber: 191951815235
Jul 12 20:38:34 alarmpi kernel: scsi host0: uas
Jul 12 20:38:34 alarmpi kernel: scsi 0:0:0:0: Direct-Access CT240BX5 00SSD1 3202 PQ: 0 ANSI: 6
Jul 12 20:38:34 alarmpi kernel: sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
Jul 12 20:38:34 alarmpi kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Jul 12 20:38:34 alarmpi kernel: sd 0:0:0:0: [sda] Write Protect is off
Jul 12 20:38:34 alarmpi kernel: sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
Jul 12 20:38:34 alarmpi kernel: sd 0:0:0:0: [sda] Disabling FUA
Jul 12 20:38:34 alarmpi kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 12 20:38:34 alarmpi kernel: sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Jul 12 20:38:34 alarmpi kernel: sda: sda1
Jul 12 20:38:34 alarmpi kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Jul 12 20:39:05 alarmpi kernel: sd 0:0:0:0: [sda] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN
Jul 12 20:39:05 alarmpi kernel: sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x28 28 00 1b f2 41 d8 00 00 28 00
Jul 12 20:39:05 alarmpi kernel: sd 0:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN
Jul 12 20:39:05 alarmpi kernel: sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x28 28 00 1b f2 41 28 00 00 a8 00
Jul 12 20:39:05 alarmpi kernel: scsi host0: uas_eh_device_reset_handler start
Jul 12 20:39:05 alarmpi kernel: usb 2-1.1: reset SuperSpeed Gen 1 USB device number 5 using xhci_hcd
Jul 12 20:39:05 alarmpi kernel: scsi host0: uas_eh_device_reset_handler success
Jul 12 20:39:35 alarmpi systemd-udevd[221]: sda: Worker [295] processing SEQNUM=2007 is taking a long time
Jul 12 20:39:36 alarmpi kernel: sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
Jul 12 20:39:36 alarmpi kernel: sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 1b f2 44 78 00 00 28 00
Jul 12 20:39:36 alarmpi kernel: sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Jul 12 20:39:36 alarmpi kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 1b f2 44 08 00 00 68 00
Jul 12 20:39:36 alarmpi kernel: sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN
Jul 12 20:39:36 alarmpi kernel: sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 1b f2 43 b8 00 00 48 00
Jul 12 20:39:36 alarmpi kernel: scsi host0: uas_eh_device_reset_handler start
Jul 12 20:39:36 alarmpi kernel: usb 2-1.1: reset SuperSpeed Gen 1 USB device number 5 using xhci_hcd
Jul 12 20:39:36 alarmpi kernel: scsi host0: uas_eh_device_reset_handler success

@M-Reimer
Copy link
Author

M-Reimer commented Jul 13, 2019

I still have the board with the "network problems":
#3034
So I moved the SD card to this board and tried the same SATA adapter.
I have exactly the same problems on this second board.
I can offer the same as I did in #3034: If it helps I can ship this hardware combination if I get paid for the hardware.

The bug is gone if I add an "usb-storage.quirks=152d:0578:u" entry to cmdline.txt but this actually disables the USB 3.0 mode (slower speed).

I guess getting the new RPi 4 working directly from the start was just too good to be true. There seem to be some driver (or even hardware?) issues left. Maybe one of the downsides of being an early adopter.

@M-Reimer
Copy link
Author

M-Reimer commented Jul 14, 2019

I got another USB3 to SATA adapter (different chipset). With this one it works immediately without errors and without additional power supply.
Maybe some kind of incompatibility between the JMicron chipset and the VIA USB host?

@P33M
Copy link
Contributor

P33M commented Jul 14, 2019

The quirk setting doesn't disable "USB3.0" mode, it disables UAS. Mass-storage accesses still go at USB3.0 speeds but things like multiple IO threads will be slower.

The adapter VID:PID already has a quirk to disable forced unit addressing but why isn't there a line appearing about a quirks match?

Can you post the output of dmesg after you've plugged the drive in with UAS disabled?

@M-Reimer
Copy link
Author

[ 67.911864] usb 2-1: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[ 67.942905] usb 2-1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=32.02
[ 67.942921] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 67.942933] usb 2-1: Product: JMS579
[ 67.942945] usb 2-1: Manufacturer: JMicron
[ 67.942957] usb 2-1: SerialNumber: 191951815235
[ 67.945341] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 67.945425] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 67.945439] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 67.946656] usb-storage 2-1:1.0: Quirks match for vid 152d pid 0578: 1800000
[ 67.946782] scsi host0: usb-storage 2-1:1.0
[ 68.952249] scsi 0:0:0:0: Direct-Access CT240BX5 00SSD1 3202 PQ: 0 ANSI: 6
[ 68.953116] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 68.953948] sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
[ 68.955015] sd 0:0:0:0: [sda] Write Protect is off
[ 68.955033] sd 0:0:0:0: [sda] Mode Sense: 47 00 00 08
[ 68.955769] sd 0:0:0:0: [sda] Disabling FUA
[ 68.955786] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 68.962294] sda: sda1
[ 68.965266] sd 0:0:0:0: [sda] Attached SCSI disk

@M-Reimer
Copy link
Author

OK. I think I can close this one. Either a broken USB 3.0 to SATA adapter or bad Linux support at all. I tried the adapter on my Linux desktop system again. It is detected fast and without errors, but so far I never tried to write to the connected SSD. When doing so, I get the error messages I've added below. I I'll send this adapter back to Amazon.

[ 501.549830] usb 2-4: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 501.567512] usb 2-4: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=32.02
[ 501.567517] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 501.567520] usb 2-4: Product: JMS579
[ 501.567523] usb 2-4: Manufacturer: JMicron
[ 501.567526] usb 2-4: SerialNumber: 191951815235
[ 501.594683] usbcore: registered new interface driver usb-storage
[ 501.599729] scsi host6: uas
[ 501.599800] usbcore: registered new interface driver uas
[ 501.600185] scsi 6:0:0:0: Direct-Access CT240BX5 00SSD1 3202 PQ: 0 ANSI: 6
[ 501.600827] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 501.601439] sd 6:0:0:0: [sdb] 468862128 512-byte logical blocks: (240 GB/224 GiB)
[ 501.601441] sd 6:0:0:0: [sdb] 4096-byte physical blocks
[ 501.601582] sd 6:0:0:0: [sdb] Write Protect is off
[ 501.601583] sd 6:0:0:0: [sdb] Mode Sense: 53 00 00 08
[ 501.601846] sd 6:0:0:0: [sdb] Disabling FUA
[ 501.601847] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 501.602086] sd 6:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[ 501.604584] sdb: sdb1
[ 501.605841] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 521.675076] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[ 573.203294] sd 6:0:0:0: [sdb] tag#29 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[ 573.203302] sd 6:0:0:0: [sdb] tag#29 CDB: Write(10) 2a 00 00 4f a0 00 00 04 00 00
[ 573.205063] sd 6:0:0:0: [sdb] tag#28 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
[ 573.205070] sd 6:0:0:0: [sdb] tag#28 CDB: Write(10) 2a 00 00 4f a4 00 00 04 00 00
[ 573.208537] sd 6:0:0:0: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
[ 573.208544] sd 6:0:0:0: [sdb] tag#27 CDB: Write(10) 2a 00 00 4f 9c 00 00 04 00 00
[ 573.212061] sd 6:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
[ 573.212068] sd 6:0:0:0: [sdb] tag#26 CDB: Write(10) 2a 00 00 4f 98 00 00 04 00 00
[ 573.215562] sd 6:0:0:0: [sdb] tag#25 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
[ 573.215568] sd 6:0:0:0: [sdb] tag#25 CDB: Write(10) 2a 00 00 4f 94 00 00 04 00 00
[ 573.219065] sd 6:0:0:0: [sdb] tag#24 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
[ 573.219072] sd 6:0:0:0: [sdb] tag#24 CDB: Write(10) 2a 00 00 4f 90 00 00 04 00 00
[ 573.222567] sd 6:0:0:0: [sdb] tag#23 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
[ 573.222573] sd 6:0:0:0: [sdb] tag#23 CDB: Write(10) 2a 00 00 4f 84 00 00 04 00 00
[ 573.226065] sd 6:0:0:0: [sdb] tag#22 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
[ 573.226072] sd 6:0:0:0: [sdb] tag#22 CDB: Write(10) 2a 00 00 4f 80 00 00 04 00 00
[ 573.229566] sd 6:0:0:0: [sdb] tag#21 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
[ 573.229572] sd 6:0:0:0: [sdb] tag#21 CDB: Write(10) 2a 00 00 4f 8c 00 00 04 00 00
[ 573.233067] sd 6:0:0:0: [sdb] tag#20 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
[ 573.233074] sd 6:0:0:0: [sdb] tag#20 CDB: Write(10) 2a 00 00 4f 88 00 00 04 00 00
[ 573.236568] sd 6:0:0:0: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
[ 573.236575] sd 6:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 00 00 4f a8 00 00 04 00 00
[ 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
[ 588.128848] audit: type=1130 audit(1563123443.566:45): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty5 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 591.551783] audit: type=1006 audit(1563123446.989:46): pid=1673 uid=0 old-auid=4294967295 auid=0 tty=tty5 old-ses=4294967295 ses=6 res=1
[ 605.630016] sd 6:0:0:0: [sdb] tag#29 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
[ 605.630024] sd 6:0:0:0: [sdb] tag#29 CDB: Write(10) 2a 00 00 57 08 00 00 04 00 00
[ 605.630813] sd 6:0:0:0: [sdb] tag#28 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
[ 605.630820] sd 6:0:0:0: [sdb] tag#28 CDB: Write(10) 2a 00 00 56 d4 00 00 04 00 00
[ 605.634285] sd 6:0:0:0: [sdb] tag#25 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
[ 605.634292] sd 6:0:0:0: [sdb] tag#25 CDB: Write(10) 2a 00 00 56 f0 00 00 04 00 00
[ 605.637815] sd 6:0:0:0: [sdb] tag#24 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
[ 605.637821] sd 6:0:0:0: [sdb] tag#24 CDB: Write(10) 2a 00 00 56 e8 00 00 04 00 00
[ 605.641291] sd 6:0:0:0: [sdb] tag#6 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
[ 605.641298] sd 6:0:0:0: [sdb] tag#6 CDB: Write(10) 2a 00 00 56 f4 00 00 04 00 00
[ 605.644810] sd 6:0:0:0: [sdb] tag#5 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
[ 605.644817] sd 6:0:0:0: [sdb] tag#5 CDB: Write(10) 2a 00 00 57 0c 00 00 04 00 00
[ 605.648319] sd 6:0:0:0: [sdb] tag#4 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
[ 605.648325] sd 6:0:0:0: [sdb] tag#4 CDB: Write(10) 2a 00 00 56 ec 00 00 04 00 00
[ 605.651810] sd 6:0:0:0: [sdb] tag#3 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
[ 605.651817] sd 6:0:0:0: [sdb] tag#3 CDB: Write(10) 2a 00 00 56 e4 00 00 04 00 00
[ 605.655309] sd 6:0:0:0: [sdb] tag#2 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[ 605.655316] sd 6:0:0:0: [sdb] tag#2 CDB: Write(10) 2a 00 00 56 e0 00 00 04 00 00
[ 605.658810] sd 6:0:0:0: [sdb] tag#1 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
[ 605.658816] sd 6:0:0:0: [sdb] tag#1 CDB: Write(10) 2a 00 00 56 dc 00 00 04 00 00
[ 605.662313] sd 6:0:0:0: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
[ 605.662320] sd 6:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 00 00 56 d8 00 00 04 00 00

@scottsweb
Copy link

I have a USB device with the same chipset and I am seeing similar issues:

[ 4877.471127] sd 1:0:0:0: [sdb] Attached SCSI disk
[ 4908.074308] sd 1:0:0:0: [sdb] tag#21 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN 
[ 4908.074326] sd 1:0:0:0: [sdb] tag#21 CDB: opcode=0x28 28 00 1b f2 41 d8 00 00 28 00
[ 4908.074463] sd 1:0:0:0: [sdb] tag#20 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN 
[ 4908.074477] sd 1:0:0:0: [sdb] tag#20 CDB: opcode=0x28 28 00 1b f2 41 28 00 00 a8 00
[ 4908.114331] scsi host1: uas_eh_device_reset_handler start
[ 4908.265195] usb 2-2: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[ 4908.300379] scsi host1: uas_eh_device_reset_handler success
[ 4938.794714] sd 1:0:0:0: [sdb] tag#25 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN 
[ 4938.794731] sd 1:0:0:0: [sdb] tag#25 CDB: opcode=0x28 28 00 00 00 00 00 00 00 08 00
[ 4938.794861] sd 1:0:0:0: [sdb] tag#23 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN 
[ 4938.794875] sd 1:0:0:0: [sdb] tag#23 CDB: opcode=0x28 28 00 1b f2 3f 88 00 00 68 00
[ 4938.834710] scsi host1: uas_eh_device_reset_handler start
[ 4938.985557] usb 2-2: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd

From lsusb:

lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 05dc:a83a Lexar Media, Inc. 
Bus 002 Device 003: 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

Other commands like blkid are locking up the device.

Is it simply a case of this device being not supported correctly?

@M-Reimer
Copy link
Author

Is it simply a case of this device being not supported correctly?

I guess so. At least this is not a "Raspberry Issue". I have exactly the same issue on my Linux desktop system (Intel i5). The correct discussion platform would be maybe the kernel mailing list or I think they also have a BugZilla setup somewhere. But I'm too busy to dig deeper into this. Was way easier to order something different and return the problematic adapter to Amazon.

@yevmoroz
Copy link

Have you guys checked this thread https://www.raspberrypi.org/forums/viewtopic.php?t=219434 ?
My current adapter is following https://www.amazon.de/dp/B00OJ3UJ2S where I have issues just as you describe.
I'm thinking of taking this one https://www.amazon.de/gp/product/B018G1RLYC/ as suggested on a thread and try it out.

@yevmoroz
Copy link

yevmoroz commented Jul 22, 2019

Also found this thread that provides some explanation to the problem https://www.raspberrypi.org/forums/viewtopic.php?t=245931.

@yevmoroz
Copy link

I tried the solution from mentioned thread, just forgot to plug in USB 2.0 port when was testing first. This is actually fine for now until, Thursday when I expect a new adapter :)

@yevmoroz
Copy link

Adapter arrived earlier 😏 I can confirm this is working like a charm with a new one. 😎

@pelwell
Copy link
Contributor

pelwell commented Jul 24, 2019

What does lsusb show for the new adapter?

@yevmoroz
Copy link

Bus 002 Device 002: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge

@pelwell
Copy link
Contributor

pelwell commented Jul 24, 2019

Thanks - from memory, I also have an adaptor with an ASMedia bridge that works well

@yevmoroz
Copy link

I've spent hours everyday trying to understand what is happening. All the time I was thinking it's yet another "Kodi caching issue" (I'm using LibreElec) and was just searching in the wrong direction. Until I remembered that I'm developer and what I can do is just look into log files and this is how I've found this thread and it helped me to solve the root cause of a problem. 😄

@FrostbyteGR
Copy link

FrostbyteGR commented Mar 4, 2020

This issue shouldn't be closed. I have a few Icy Box IB-183M2 adapters which are based on JMicron's JMS579 chipset and they exhibit the same problem with UAS over USB3.0. The adapters work fine under USB2.0 on the Raspberry Pi 4 and on x86 under USB3.0, without quirks and UAS enabled.
This issue probably pertains to VL805 firmware or the Raspberry kernel and both of those are the vendor's responsibility to fix.

@JamesH65
Copy link
Contributor

JamesH65 commented Mar 4, 2020

This issue probably pertains to VL805 firmware or the Raspberry kernel and both of those are the vendor's responsibility to fix.

We have no access to the source of the VL805 firmware, so we are forced to rely on the manufacturers to fix any problems. Much of the code in the kernel comes from upstream as well, so again, whilst we will do our best to find issues, it's very difficult when it comes from somewhere else and you have no experience in that area.

@FrostbyteGR
Copy link

This issue probably pertains to VL805 firmware or the Raspberry kernel and both of those are the vendor's responsibility to fix.

We have no access to the source of the VL805 firmware, so we are forced to rely on the manufacturers to fix any problems. Much of the code in the kernel comes from upstream as well, so again, whilst we will do our best to find issues, it's very difficult when it comes from somewhere else and you have no experience in that area.

I understand your position, but I still believe that we shouldn't be of the mentality "it's not our problem, case closed". Especially so when it's a non-issue on other architectures (x86_64) and on USB2.0 on the affected platform (Raspberry). One of the main reasons behind Raspberry Pi 4's attractiveness is the USB3.0 capabilities (so we're finally spared from the SD card's poor I/O and durability), sadly everything but that works flawlessly. At this point I would also like to point out that JMicron's JMS578 and JMS579 chipsets are very popular choices for the majority of USB-to-SATA/M.2 adapters and that is going to cause a lot of headaches. At the very least, if the team itself is not able to provide with a solution, the issue should be forwarded to whomever is responsible or can provide with a fix. Please keep this issue open and update us in light of new developments.

@JamesH65
Copy link
Contributor

JamesH65 commented Mar 4, 2020

This issue probably pertains to VL805 firmware or the Raspberry kernel and both of those are the vendor's responsibility to fix.

We have no access to the source of the VL805 firmware, so we are forced to rely on the manufacturers to fix any problems. Much of the code in the kernel comes from upstream as well, so again, whilst we will do our best to find issues, it's very difficult when it comes from somewhere else and you have no experience in that area.

I understand your position, but I still believe that we shouldn't be of the mentality "it's not our problem, case closed". Especially so when it's a non-issue on other architectures (x86_64) and on USB2.0 on the affected platform (Raspberry). One of the main reasons behind Raspberry Pi 4's attractiveness is the USB3.0 capabilities (so we're finally spared from the SD card's poor I/O and durability), sadly everything but that works flawlessly. At this point I would also like to point out that JMicron's JMS578 and JMS579 chipsets are very popular choices for the majority of USB-to-SATA/M.2 adapters and that is going to cause a lot of headaches. At the very least, if the team itself is not able to provide with a solution, the issue should be forwarded to whomever is responsible or can provide with a fix. Please keep this issue open and update us in light of new developments.

"Whilst we do our best to fix issues" does not mean "it's not our problem". We send test cases to VIA when repeatable bugs arise, and we also report and try to fix bug with upstream code when we can. Assuming we just sit on our hands and do nothing is plain rude.

@FrostbyteGR
Copy link

This issue probably pertains to VL805 firmware or the Raspberry kernel and both of those are the vendor's responsibility to fix.

We have no access to the source of the VL805 firmware, so we are forced to rely on the manufacturers to fix any problems. Much of the code in the kernel comes from upstream as well, so again, whilst we will do our best to find issues, it's very difficult when it comes from somewhere else and you have no experience in that area.

I understand your position, but I still believe that we shouldn't be of the mentality "it's not our problem, case closed". Especially so when it's a non-issue on other architectures (x86_64) and on USB2.0 on the affected platform (Raspberry). One of the main reasons behind Raspberry Pi 4's attractiveness is the USB3.0 capabilities (so we're finally spared from the SD card's poor I/O and durability), sadly everything but that works flawlessly. At this point I would also like to point out that JMicron's JMS578 and JMS579 chipsets are very popular choices for the majority of USB-to-SATA/M.2 adapters and that is going to cause a lot of headaches. At the very least, if the team itself is not able to provide with a solution, the issue should be forwarded to whomever is responsible or can provide with a fix. Please keep this issue open and update us in light of new developments.

"Whilst we do our best to fix issues" does not mean "it's not our problem". We send test cases to VIA when repeatable bugs arise, and we also report and try to fix bug with upstream code when we can. Assuming we just sit on our hands and do nothing is plain rude.

I was strictly referring to the fact that this specific issue has been closed, the lack of communication regarding this specific issue (and family of adapters) on the corresponding forum thread and the proposed solution being to "simply acquire a compatible adapter" instead. Nowhere did I assume or otherwise state that the team is idling on purpose or not. Let us not derail the discussion any further due to this misunderstanding (and my apologies for that). I propose opening a new issue to track this, since this one has been closed by the author.

@FrostbyteGR
Copy link

FrostbyteGR commented Mar 16, 2020

Can we get an update on the situation or at least a new issue to track this?
If there's no plan on fixing JMS579 and JMS578 based adapters, then at least provide us with an official list of known good adapters (both for SATA and M.2 B/B+M key drives) that have been tested and work properly/fully-functional with the Raspberry Pi 4B.

@P33M
Copy link
Contributor

P33M commented Mar 16, 2020

Adapter/device whitelists don't work. There hasn't been, and will never be, a curated set of third-party USB devices that are "known good" because manufacturers frequently change chipset revisions and the firmware that runs on them.

This is why this thread exists (linked above): https://www.raspberrypi.org/forums/viewtopic.php?t=245931

Have you tried connecting your adapters to the USB3.0 port and setting the cmdline.txt quirk?

@FrostbyteGR
Copy link

FrostbyteGR commented Mar 16, 2020

Adapter/device whitelists don't work. There hasn't been, and will never be, a curated set of third-party USB devices that are "known good" because manufacturers frequently change chipset revisions and the firmware that runs on them.

This is why this thread exists (linked above): https://www.raspberrypi.org/forums/viewtopic.php?t=245931

Have you tried connecting your adapters to the USB3.0 port and setting the cmdline.txt quirk?

I am aware of the thread and have perused it extensively.
Utilizing quirks (as I mentioned earlier) does work for the time being, but I'd like to have a proper long-term solution (uas instead of usb-storage) in place, to leverage the full capabilities (along with a tiny bit of extra performance and lifespan possibly) that an M.2 SSD can offer. It's just that I'm (among several other users, I suppose) struggling to find such solution.
Thank you for understanding and the time/effort you've put into this matter.

@SDClass
Copy link

SDClass commented Apr 12, 2020

The issue for me stopped when I moved my USB drive from the RPi4's USB 3.0 slot, to the USB 3.0 4-port hub that I added to my system. It's a bit expensive but I like it's size and it's ability to power it from a micro USB cord and 5v power source if needed. So far, I haven't needed to add power to it. It's a bit on the expensive side so I'm assuming any 3.0 hub would also do the trick.

UGREEN USB 3.0 Hub 4 Port Ultra Slim Data Hub with 5V Micro USB Power Compatible for MacBook Mac Pro Mini, iMac, Surface Pro, XPS, IdeaPad, MateBook X Pro, Notebook PC, USB Flash Drives, Mobile HDD

@FrostbyteGR
Copy link

Any updates from VIA?

@JazzTp
Copy link

JazzTp commented Jul 21, 2020

[...] so I'm assuming any 3.0 hub would also do the trick. [...]

This one didn't solve the issue, it's possible on the contrary that errors are more frequent than without it, also with a good power supply plugged in:

https://articulo.mercadolibre.com.ar/MLA-857246129-adaptador-hub-usb-30-a-4-puertos-usb-30-alimentacion-exter-_JM?quantity=1#position=37&type=item&tracking_id=ea39649e-9b91-4f50-93f4-bde723f58611


Let me add a rant here, just to put some weight on the "please fix it" side of the thread:

I wonder how many man-hours this thing will have eaten before VIA provides a fix and the fix is made available and well visible for Raspberry PI newcomers, I wish raspberrypi.org had put a very well visible note on their homepage :-|

I'm another of many who's lost some hours (*) discarding other possible sources of the problem, updating upgrading, checking - via another machine - the ssd for bad sectors, getting source code for binaries I was suspecting might have been compiled with libraries not totally compatible with the Raspberry PI and recompiling from source, ordering a powered hub in case the problem was power related (I'm testing the same disk+case on a USB2 port right now... although without that hub because apparently the Raspberry PI won't boot through it on USB2, while it does on USB3... well... I might always go back to booting from an SDcard and putting the external disk in fstab, if not directly as root in /boot/cmdline.txt).

Considering that I'm personally in constant lack of time and considering that this is a deviation from priorities, I have my Dutch friend's words resonating in my ears, "any low end PC will give any Raspberry PI a run for that price".

But I love the small thing idea with the GPIO pins LOL.

@FrostbyteGR
Copy link

Hubs are not a valid solution if you have a cluster of Pi's, I am pretty sure the reasons are easy to imagine.

@JazzTp
Copy link

JazzTp commented Jul 21, 2020

Hubs are not a valid solution if you have a cluster of Pi's, I am pretty sure the reasons are easy to imagine.

(I understand that the quoted message, to which I had at first replied, was not addressed to me: I see in my e-mail inbox a post from another user, deleted afterwards apparently, who's running a cluster of 8 Pi's fed via PoE. The comment was actually about hubs not being an acceptable solution.)

@FrostbyteGR
Copy link

FrostbyteGR commented Jul 21, 2020

Hubs are not a valid solution if you have a cluster of Pi's, I am pretty sure the reasons are easy to imagine.

(I understand that the quoted message, to which I had at first replied, was not addressed to me: I see in my e-mail inbox a post from another user, deleted afterwards apparently, who's running a cluster of 8 Pi's fed via PoE. The comment was actually about hubs not being an acceptable solution.)

That user was me, I decided to delete and rewrite my response, because I felt it was maybe too hostile/whiny.
Yes, it wasn't addressed to you, I just felt triggered because I was reminded that I was proposed such a solution.
I own a PoE-fed cluster of these bad boys and hubs are not a convenient way to go about it, for multiple reasons.
I'll just dish out for a new set of adapters and hope their controllers play nice. There go 270+ euros, if the first one proves functional.

@bjoernricks
Copy link

Hi,

I have found this issue while having connection problems with the 2.4GHz Wifi on my new Raspi 4b. It worked without problems at the beginning but suddenly it couldn't connect to the Wifi network anymore. After playing around for several hours I found out that the 5 GHz network works and thought that something must be wrong with the Wifi firmware or the regulation settings. But I couldn't get the 2.4 GHz network to a working state.

Some days later I suddenly remembered the thing I've changed between working and not working 2.4 GHz Wifi. I had plugged in an external USB 3.0 hard disk which I didn't used yet because of the network problems. After removing the device the Wifi just worked as expected again. My USB device uses a JMS579 (152d:1576) and if that one is plugged in during boot the Wifi network just doesn't work. It is reproducible with every boot. Sadly deactivating uas has no influence on this behavior. The only solution for me was to connect the hard disk to a USB 2.0 slot. I really don't know why this has influence to the Wifi driver and I can't imagine what's happening here.

@max17048
Copy link

I have found this issue while having connection problems with the 2.4GHz Wifi on my new Raspi 4b. It worked without problems at the beginning but suddenly it couldn't connect to the Wifi network anymore. After playing around for several hours I found out that the 5 GHz network works and thought that something must be wrong with the Wifi firmware or the regulation settings. But I couldn't get the 2.4 GHz network to a working state.

2.4GHz: Try to disable Bluetooth in /boot/config.txt. Check #3727

@bjoernricks
Copy link

2.4GHz: Try to disable Bluetooth in /boot/config.txt. Check #3727

Both work with using USB 2.0 for my hard disk.

@pelwell
Copy link
Contributor

pelwell commented Aug 14, 2020

USB3 is known to interfere with the 2.4G WiFi band - this is a general problem. Search for "usb3 wifi interference" for more information.

@bjoernricks
Copy link

USB3 is known to interfere with the 2.4G WiFi band - this is a general problem. Search for "usb3 wifi interference" for more information.

Thanks. I wasn't aware of that.

@rkkoszewski
Copy link

I've also seen this issue again recently. My plan was to set up a TV streaming server with recording capability on a RPi 4. To do this I had to add a big storage device. So I ordered an off-the-shelf 4TB USB HDD which, once again, has the issue described here. Recording failed regularly as the HDD was set to read only by the kernel. I disabled UAS for this drive and now everything is rock stable.

This most probably is an issue directly inside the kernel with this JMicron chipset. I wouldn't even say that the VIA chip is involved in this. I had the UAS errors on my Desktop machine, too. Discussing this here may be the wrong place. Someone with at least basic knowledge would have to move this discussion to LKML. If there is no solution for this, then the kernel should at least not even try to use UAS for this chipset.

Disabling UAS does not fix the issue, but merely makes it harder to hit the condition for it to fail. At least on my JMS561 (Dual hard drive bay) when both drives are reading or writing on full speed it manages to hit the issue even with UAS disabled for the drives (It takes longer though). Perhaps on single drive enclosures disabling UAS could mitigate the issue better.

@skeller
Copy link

skeller commented Aug 21, 2020

I want to add that disabling UAS for JMS578 is not the solution. I have several JMS578 enclosures and they all work fine on different laptops and desktop machines (all Intel based). In UAS mode they outperform by far classic mass-storage. Also they support SCSI UNMAP -> SATA TRIM mapping which also works fine (and allows you to use fstrim e.g.).
Given that the Via hub in the Pi4 has problems with other hardware as well (e.g. I have a full-speed battery charger which isn't even recognized at all unless I put a 2.0 hub inbetween), I'm quite sure that the problem is the crappy Via USB implementation and not the JMS bridge.
@pelwell Why do you think the JMS is "strange"? Just because of that FUA quirk? That is really a non-issue.

@pelwell
Copy link
Contributor

pelwell commented Aug 21, 2020

I don't think the JMS is strange - the "it" in that sentence does not refer to the JMS.

@chaserene
Copy link

I got another USB3 to SATA adapter (different chipset). With this one it works immediately without errors and without additional power supply.

@M-Reimer which model/chipset did you buy when you wrote that?

@FrostbyteGR
Copy link

Small heads-up for anyone else who's planning on getting Icy Box adapters:
I ended up acquiring IB-184M2 adapters, which are based on ASMedia ASM1351 (to replace my IB-183M2 ones, based on JMicron JMS579). They're a little bit more expensive, but they ended up working fine, UAS and all.

@phmio
Copy link

phmio commented Nov 1, 2020

Hello,

Like @FrostbyteGR I also have several IB-183M2's that have some troubles with USB3 on a PI4.

  • The IB-183M2 didn't support TRIM, but my SSD does.
$ sudo hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read data after TRIM

$ sudo fstrim -v /
strim: /: the discard operation is not supported

To fix it I had to update the firmware from version 2.04 to version 5.08, and now TRIM works. 👍

  • Connecting it to the USB3 ports, it is well recognized as Driver=uas, but generates many errors such as uas_eh_abort_handler, uas_eh_device_reset_handler, uas_zap_pending, etc... not very reassuring.
$ lsusb
Bus 002 Device 002: ID 152d:1576 JMicron Technology Corp. / JMicron USA Technology Corp.

$ lsusb -t
/:  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
  • I have also tested the Quirk mode and the adapter works better but in Driver=usb-storage, however in this mode TRIM is not possible anymore 😞

  • Next I have connected it to the USB2 ports and... everything works fine ! 👍
    Driver=uas ok
    TRIM ok
    and no more uas_* errors
    But the access times are not so good 😞

Some speed tests:

USB3 Write:
$ dd bs=1M count=256 if=/dev/zero of=tempfile conv=fdatasync
268435456 bytes (268 MB, 256 MiB) copied, 1.89437 s, 142 MB/s
USB3 Read:
$ sudo hdparm -Tt /dev/sda
 Timing cached reads: 1598 MB in 2.00 seconds = 798.96 MB/sec
 Timing buffered disk reads: 1034 MB in 3.00 seconds = 344.33 MB/sec

USB2 Write:
$ dd bs=1M count=256 if=/dev/zero of=tempfile conv=fdatasync
268435456 bytes (268 MB, 256 MiB) copied, 8.92886 s, 30.1 MB/s
USB2 Read:
sudo hdparm -Tt /dev/sda
 Timing cached reads: 1552 MB in 2.00 seconds = 776.66 MB/sec
 Timing buffered disk reads: 104 MB in 3.04 seconds = 34.16 MB/sec

To conclude, I think like @FrostbyteGR that there is really a problem with the VIA VL805 firmware on the USB3 ports. All my adapters with JMS578/JMS579 USB3 controllers are all working OK in Linux on my Desktop PC which uses another USB3 controller type.
It's a pity that VIA doesn't want to take into account and fix this problem, there are still a lot of USB3 devices with JMS578/JMS579 controllers.

@FrostbyteGR does the IB-184M2 (ASMedia ASM1351) support SSD TRIM?

@FrostbyteGR
Copy link

FrostbyteGR commented Nov 3, 2020

@phmio I'm trying to test it for you (though I'm using CentOS 8 aarch64), however it seems that the adapter is not passing TRIM

# sg_readcap -l /dev/sda | grep lbpme
   Logical block provisioning: lbpme=0, lbprz=0
# sg_vpd -a /dev/sda | grep 'Unmap command supported (LBPU): 1'
# hdparm -I /dev/sda | grep TRIM
*    Data Set Management TRIM supported (limit 8 blocks)
*    Deterministic read data after TRIM
# fstrim -v /
fstrim: /: the discard operation is not supported
# lsblk --discard /dev/sda
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0        0B       0B         0
├─sda1        0        0B       0B         0
├─sda2        0        0B       0B         0
└─sda3        0        0B       0B         0

Making a udev rule, like the following (VID and PID can be found through lsusb), sadly doesn't help in this case

echo 'ACTION=="add|change", ATTRS{idVendor}=="<VID>", ATTRS{idProduct}=="<PID>", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' > /etc/udev/rules.d/50-usb-ssd-trim.rules

I would also like to provide proof that UAS works out-of-the-box on USB3 ports with IB-184M2 (based on ASMedia ASM1351) adapters

# lsusb
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
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 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

Interestingly enough, a user over the raspberry pi forums has reported that TRIM is working fine for another ASM1351-based adapter with the same VID/PID information as IB-184M2. That makes me believe that a firmware update is in order, before we can hope on getting TRIM working, here as well.

Having said so, I would like to inquire on how you were able to procure a firmware update, as I'm unable to locate any (for both IB-183M2 and IB-184M2 devices) on RaidSonic's website.
Just so we don't derail this thread with irrelevant information (such as further details on the acquisition of firmware updates for the aforementioned adapters) you may find my email address on any of my personal repositories.

@JazzTp
Copy link

JazzTp commented Nov 3, 2020

Just so we don't derail this thread with irrelevant information (such as further details on the acquisition of firmware updates for the aforementioned adapters)

Please do share here, that would be valuable information, additional value for this thread.

@FrostbyteGR
Copy link

I opened a support ticket to RaidSonic for this and their reply was the following:

IB-184M2 don’t support TRIM. We know this.
At IB-1818-U31 TRIM work
image
https://www.raidsonic.de/en/standards/searchresults.php?we_objectID=5839

What we can surmise from this, is that they won't bother issuing an official firmware update to fix this, even though it can be fixed with one. They instead directed me to another one of their products, to get what I want.
The concern here is that with VL805's quirkiness, it's not guaranteed that the VL716 chip (found in IB-1818-U31) will play nice and have everything work (UAS, TRIM, etc) out-of-the-box. I guess my only option is to buy one and test..

@phmio
Copy link

phmio commented Nov 3, 2020

Thanks @FrostbyteGR for testing the IB-184M2 adapter. I also have contacted RaidSonic support to ask them if they have a more recent version of the firmware for the IB-183M2 and they provided me this version 5.08.

@babacs
Copy link

babacs commented Nov 9, 2020

you may add 0080:a001 ORICO mSATA SSD box 3.0 USB with UAS (MSG-U3) to the non working list as of today
https://www.orico.cc/us/product/detail/3686.html
:(
I works with UAS turned off, native USB3 mode with quirks.
If any more details needed, I'm happy to provide.

@FrostbyteGR
Copy link

FrostbyteGR commented Nov 10, 2020

@phmio So, the product RaidSonic's support proposed, arrived today in the mail and I tested it..

Adapter: Icy Box IB-1818-U31
Chipset: VIA VL716

UAS appears to work fine out-of-the-box..

# lsusb
Bus 002 Device 002: ID 2109:0716 VIA Labs, Inc.
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 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

lbpme=0 here too, but the unmap command is supported this time around..

# sg_readcap -l /dev/sda | grep lbpme
   Logical block provisioning: lbpme=0, lbprz=0
# sg_vpd -a /dev/sda | grep 'Unmap command supported (LBPU): 1'
  Unmap command supported (LBPU): 1
# hdparm -I /dev/sda | grep TRIM
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read data after TRIM

So, all we gotta do is add a udev rule and reboot..

echo 'ACTION=="add|change", ATTRS{idVendor}=="2109", ATTRS{idProduct}=="0716", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' > /etc/udev/rules.d/50-usb-ssd-trim.rules

TRIM seems to be working, I think..

# fstrim -v /
/: 334 MiB (350257152 bytes) trimmed
# lsblk --discard /dev/sda
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       4G         0
├─sda1        0      512B       4G         0
├─sda2        0      512B       4G         0
└─sda3        0      512B       4G         0

My only gripe with the adapter, is that it's casing is too wide and it ends up blocking the Ethernet port.
I ended up using it in it's bare-PCB form (without it's casing), lets hope nothing bad happens..
EDIT: On second thought I decided to opt for some 0.15m USB3.0 extension cables instead of removing the casing, let's hope they don't cause issues..

@phmio
Copy link

phmio commented Nov 11, 2020

Thanks @FrostbyteGR for your sharing

I have done a quick look at the scsi driver sources code (drivers\scsi\sd.c) and indeed when lbpme=0 all the initialization logic of the unmap mode for the provisioning_mode is not done automatically by Linux, and we have to add manually a udev rule.

So I don't understand why some USB adapter manufacturers don't set lbpme=1 in their firmware knowing that they set LBPU=1 (Unmap command supported) to signal to the system that it is possible to use unmap commands to do TRIM...

@tablatronix
Copy link

JMC583 here, pretty much same issues, thanks for the posts, so much time and money wasted on this. We definitely need a database for compatibility for these.

@mirh
Copy link

mirh commented Jan 7, 2021

EEPROM version seems also pretty relevant
home-assistant/operating-system#1103

@tablatronix
Copy link

Uas turned off has been working ok, under extreme activity I get read fails and usb restarts. Some discussion on firmware also over on iotstack, wifi/usb issues etc. i think my fw was sep

@Jannomag
Copy link

I'm facing the same issue. Here's my dmesg:
https://pastebin.com/XwWgdBH7

Any workaround for JSM567, yet? Or any recommendation for another USB 3.0 2.5" case or adapter?
I'm using a Samsung 840 SSD in an external case.
The error appears when I try to copy my backed up files from another external HDD (with external power supply) to the ssd, which is also the boot drive and roots.

It bugs me slot because I'm trying to figure out what's wrong for 2 days. The ssd worked well before without any errors at all.

@madskonradsen
Copy link

Man... the amount of hours spend before arriving at this ticket. Could RP devs please put some pressure on VIA Labs and make them issue a firmware update...

@rkkoszewski
Copy link

Man... the amount of hours spend before arriving at this ticket. Could RP devs please put some pressure on VIA Labs and make them issue a firmware update...

Not a Raspberry Pi only issue. Had the same happening on an Intel N4200, also VIA chipset and a JSM567 controller.

@madskonradsen
Copy link

Man... the amount of hours spend before arriving at this ticket. Could RP devs please put some pressure on VIA Labs and make them issue a firmware update...

Not a Raspberry Pi only issue. Had the same happening on an Intel N4200, also VIA chipset and a JSM567 controller.

Sure :) But the amount of RP4’s being shipped is pretty huge and one of the key selling points was USB3(with USB3 boot) And it might as well be the RP devs that puts Via Labs to work.

@P33M
Copy link
Contributor

P33M commented Feb 26, 2021

This thread has gone off in so many different directions that I am locking it. Github issues are not a catch-all for "my USB SSD adapter doesn't work" - which can due to a number of different reasons. Support requests should be made via the Troubleshooting section of the Raspberry Pi forums.

Since Github keeps collapsing the thread and omitting important points, I'll reiterate them one last time:
UAS can be disabled as a workaround for chipsets that have incompatible UAS implementations. See here:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931

Many bus-powered adapters do not conform to the USB maximum input current requirements and will suffer unreliable operation when plugged directly into the Pi's USB ports. Use a powered USB hub in these cases, or if more than one SSD adapter is going to be used.

Adapter/device whitelists don't work. There hasn't been, and will never be, a complete curated set of third-party USB devices that are "known good" because manufacturers frequently change chipset revisions and the firmware that runs on them.

@raspberrypi raspberrypi locked as off-topic and limited conversation to collaborators Feb 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests