USB3.0 to SATA adapter causes problems #3070
Comments
|
I still have the board with the "network problems": 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. |
|
I got another USB3 to SATA adapter (different chipset). With this one it works immediately without errors and without additional power supply. |
|
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? |
|
[ 67.911864] usb 2-1: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd |
|
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 |
|
I have a USB device with the same chipset and I am seeing similar issues: From Other commands like 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. |
|
Have you guys checked this thread https://www.raspberrypi.org/forums/viewtopic.php?t=219434 ? |
|
Also found this thread that provides some explanation to the problem https://www.raspberrypi.org/forums/viewtopic.php?t=245931. |
|
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 :) |
|
Adapter arrived earlier |
|
What does lsusb show for the new adapter? |
|
|
|
Thanks - from memory, I also have an adaptor with an ASMedia bridge that works well |
|
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. |
|
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. |
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. |
|
Can we get an update on the situation or at least a new issue to track this? |
|
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. |
|
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. |
|
Any updates from VIA? |
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: 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. |
|
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. |
|
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. |
2.4GHz: Try to disable Bluetooth in /boot/config.txt. Check #3727 |
Both work with using USB 2.0 for my hard disk. |
|
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. |
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. |
|
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.). |
|
I don't think the JMS is strange - the "it" in that sentence does not refer to the JMS. |
@M-Reimer which model/chipset did you buy when you wrote that? |
|
Small heads-up for anyone else who's planning on getting Icy Box adapters: |
|
Hello, Like @FrostbyteGR I also have several IB-183M2's that have some troubles with USB3 on a PI4.
To fix it I had to update the firmware from version 2.04 to version 5.08, and now TRIM works.
Some speed tests: 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. @FrostbyteGR does the IB-184M2 (ASMedia ASM1351) support SSD TRIM? |
|
@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 Making a udev rule, like the following (VID and PID can be found through 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 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. |
Please do share here, that would be valuable information, additional value for this thread. |
|
I opened a support ticket to RaidSonic for this and their reply was the following:
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. |
|
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. |
|
you may add 0080:a001 ORICO mSATA SSD box 3.0 USB with UAS (MSG-U3) to the non working list as of today |
|
@phmio So, the product RaidSonic's support proposed, arrived today in the mail and I tested it.. Adapter: Icy Box IB-1818-U31 UAS appears to work fine out-of-the-box.. lbpme=0 here too, but the unmap command is supported this time around.. So, all we gotta do is add a udev rule and reboot.. TRIM seems to be working, I think.. My only gripe with the adapter, is that it's casing is too wide and it ends up blocking the Ethernet port. |
|
Thanks @FrostbyteGR for your sharing I have done a quick look at the scsi driver sources code (drivers\scsi\sd.c) and indeed when So I don't understand why some USB adapter manufacturers don't set |
|
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. |
|
EEPROM version seems also pretty relevant |
|
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 |
|
I'm facing the same issue. Here's my dmesg: Any workaround for JSM567, yet? Or any recommendation for another USB 3.0 2.5" case or adapter? 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. |
|
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. |
|
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: 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. |
and others
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
The text was updated successfully, but these errors were encountered: