AData SD600 ssd not working on USB 3 ports

[ejjaquay]

I purchased an ADATA SD600 SSD with the intention of using in on my new Raspberry Pi 4B which is running headless via SSH. I attached the SSD to the USB 3 port and was able to reformat it to ext4 and copied some smaller files using SSH to it no problems but when I tried to copy several large (~1.6GB) files the transfer locked up and the system slowed to a crawl. dmesg indicated a large number of usb controller resets and other strange kernel warnings. I was unable to kill the transfer so I attempted a reboot which hung. So I powered down and reset but the pi would not even boot. I removed the ssd and the system booted. A second attempt to copy the files produced similar results so I connected the SSD to a USB 2.0 port to see if that would work. It did. SSD is working fine on USB 2.0 no boot problems and no errors recorded after 3 days of testing it. I then moved the SSD to my old Toshiba laptop running Ubuntu 18.04 and tested it there to see if the problem is with the drive. I seems to work perfectly connected to my laptop 3.0 ports so the problem must be with drivers/firmware in raspberry pi. My question: Can this be issue be fixed or is there a work around? ADATA SD600 is a very popular and low priced device. It would be a shame it raspberry can not support it.

Here is example of error messages with SSD plugged into 3.0 port:

/var/log/messages:Jul 8 22:52:23 rpi5 kernel: [10590.758686] sd 0:0:0:0: [sda] tag#19 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
/var/log/messages:Jul 8 22:52:23 rpi5 kernel: [10590.758699] sd 0:0:0:0: [sda] tag#19 CDB: opcode=0x2a 2a 00 00 39 10 00 00 00 08 00
/var/log/messages:Jul 8 22:56:10 rpi5 kernel: [10818.604454] sd 0:0:0:0: [sda] tag#19 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
/var/log/messages:Jul 8 22:56:10 rpi5 kernel: [10818.604466] sd 0:0:0:0: [sda] tag#19 CDB: opcode=0x2a 2a 00 00 32 38 60 00 00 08 00

[ejjaquay]

I think I found the issue. The AData SD600 does not seem to support UAS, at least not on the raspberry. The work around is to blacklist UAS for the device. I did this by adding the following argument to the boot command line (/boot/cmdline.txt) and rebooting:

usb-storage.quirks=125f:a68a:u

Where 125f:a68a is the device id from lsusb for the SSD

After reboot dmesg reports UAS is blacklisted:

[ 125.203379] usb 2-1: Product: SD600
[ 125.203391] usb 2-1: Manufacturer: ADATA
[ 125.203402] usb 2-1: SerialNumber: ***************
[ 125.206337] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 125.206428] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 125.206442] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 125.207122] usb-storage 2-1:1.0: Quirks match for vid 125f pid a68a: 800000
[ 125.207251] scsi host0: usb-storage 2-1:1.0

The drive now works without error and is 10 times faster on USB3 than USB2

[pik33]

This cmdline trick also "repaired" my USB3 incompatible enclosure. This topic should be pinned and called "How to make a USB3 incompatible drive work".

[lpsw]

I had to do the same to get my SSD to run from a USB3 port. It ran fine on a USB2 port.

SATA controller:
ID 152d:1561 JMicron Technology Corp. JMS561U

SSD:
KINGSTON SA400S37240G; firmware revision SBFKB1D1

[pik33]

My chip is 152d:0578 - also JMicron

[Mastiff]

ejjaquay, hallelujah! Thanks for saving my sanity (even though some may say that it's long gone...)! I had done a few days of trying to get this to work with different combinations and I was about to order a new, much more expensive SSD box when another user linked me to this thread. JMicron 152d:0578, of course. I have the SSD on one of the USB 3 ports, a Logitech Unifying on the other (works just as well on the USB 2 port, of course) and a Tellstick Duo on one of the USB 2 ports. I am going to do a few hours boot cycle first of all now. It's based on MQTT, to make it a bit more random. Node-RED connects to the broker and reboots the Pi when it gets a particular signal from any of the Termostats in the Z-Wave network, so it varies between five seconds after Node-RED is started and up to maybe a minute. So far more than 15 reboots without problems. And they're blistering fast compared to both the Pi 3 with SSD and Pi 4 with an SD card.

[LesGirauds]

I think I'm seeing the same problem with my Toshiba drive - in that the symptoms sound the same. It's performance when connected on a USB2 port is as expected (that is, same as the older Pi it replaced) But I face problems when it is connected to USB3 port - I can mount the drive ok, it's recognisable and browsable (Samba) but copying to/from is woefully slow (WAY slower than USB2) and the Pi slowly grounds to a halt.

However, I cannot seem to blacklist UAS for the Toshiba - and I think I've followed the instructions.

lsusb

Code: Select all

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 0480:a20b Toshiba America Inc 
Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port 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

cmdline.txt

Code: Select all

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=54315418-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
usb-storage.quirks=0480:a20b:u

The drive is mounted with the UUID in fstab. I'm not seeing confirmation of the blacklisting in dmesg however. Where am I going wrong?

[drgeoff]

See sticky https://www.raspberrypi.org/forums/view ... 8&t=245931

[LesGirauds]

See sticky https://www.raspberrypi.org/forums/view ... 8&t=245931

Thanks, that's given me something to go on. Mine's a SCSI drive and I don't know whether that changes things. I've started a new thread.

[HappyOz]

Thanks again for this thread, still very current and helpful.

I've had trouble today with a Crucial BX500 in an external USB enclosure. Worked on USB2, did not work on USB3.

After adding

Code: Select all

usb-storage.quirks=152d:0578:u

to the cmdline.txt everything appears to be fine now.

I'm now successfully booting off the drive.

[thorvick]

I created an account just to say thank you because I have been looking for a fix for ages.
Same issue with my Samsung SSD 860 EVO (152d:0578 JMicron Technology Corp). It was working for a while since I bought it in January and then out of nowhere started appearing on and off and disappearing in the middle of transfers...