0

I have a 500gb ssd in a seagate usb3 enclosure that I want to use as external storage on my raspi 4. This disk is recognized and can be formatted by my Mac, so I know the drive is good.

When I plug the drive into a usb3 port and run fdisk -l, the command outputs info for /dev/ram# and /dev/mmcblk0 and then hangs, never exiting.

/dev/sda exists once the drive is plugged in and lsusb lists the seagate device.

Any ideas?

EDIT: Output of dmesg per @JaromandaX suggestion:

[Feb14 14:38] usb 2-2: new SuperSpeed Gen 1 USB device number 97 using xhci_hcd
[  +0.030678] usb 2-2: New USB device found, idVendor=0bc2, idProduct=ab24, bcdDevice= 1.00
[  +0.000015] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[  +0.000013] usb 2-2: Product: BUP Slim
[  +0.000012] usb 2-2: Manufacturer: Seagate
[  +0.000012] usb 2-2: SerialNumber: 2HC015KJ
[  +0.008228] scsi host0: uas
[  +0.010986] scsi 0:0:0:0: Direct-Access     Seagate  BUP Slim         0304 PQ: 0 ANSI: 6
[  +0.001330] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  +0.000416] sd 0:0:0:0: [sda] Spinning up disk...
[  +1.078004] .................................................................................................not responding...
[Feb14 14:40] sd 0:0:0:0: [sda] 1000215215 512-byte logical blocks: (512 GB/477 GiB)
[  +0.000014] sd 0:0:0:0: [sda] 2048-byte physical blocks
[ +20.849826] sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
[  +6.950121] sd 0:0:0:0: [sda] Asking for cache data failed
[  +0.000016] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  +0.000722] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (2048 bytes)
[  +0.000805] sd 0:0:0:0: [sda] Spinning up disk...
[Feb14 14:41] .................................................................................................not responding...
[Feb14 14:43] sd 0:0:0:0: [sda] tag#5 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD IN 
[  +0.000018] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x28 28 00 00 00 00 07 00 00 01 00
[  +0.000236] sd 0:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD IN 
[  +0.000014] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x28 28 00 00 00 00 06 00 00 01 00
[  +0.000287] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN 
[  +0.000012] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x28 28 00 00 00 00 05 00 00 01 00
[  +0.000286] sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN 
[  +0.000013] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 00 00 00 04 00 00 01 00
[  +0.039165] scsi host0: uas_eh_device_reset_handler start
[  +0.150920] usb 2-2: reset SuperSpeed Gen 1 USB device number 97 using xhci_hcd
[  +0.035044] scsi host0: uas_eh_device_reset_handler success
4
  • 1
    check the output of dmesg once you've plugged the device in, and then, in another terminal, once you've run that command Feb 14 at 1:42
  • @JaromandaX added dmesg output to my op. Feb 14 at 14:42
  • if you open another terminal (or another ssh) does it too freeze when you run fdisk -l on the first terminal/session - clearly you can see ....not responding. right? Feb 14 at 21:18
  • Perhaps try lsblk --fs instead of fdisk -l? man fdisk => manipulate disk partition table ... is that what you're trying to do? Or - man lsblk => list block devices ?
    – Seamus
    Mar 1 at 0:52
1

This seems to be an UAS issue. Try blacklisting the UAS driver for your SSD via usb-storage.quirks=<VID>:<PID>:u kernel parameter.

0

This is possibly an issue with the adapter: See https://github.com/raspberrypi/linux/issues/3070.

If it is the case, you will have to use the mass-storage driver instead of the default uas driver. There are drawbacks (no TRIM for instance), but at least it will allow you to use the drive with correct performance.

To do so, find out your device USB IDs with lsusb:

br@idril:~$ lsusb
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

In my case, Vendor ID is 152d, and Product ID is 0578.

I changed /boot/cmdline.txt from:

console=serial0,115200 console=tty1 root=PARTUUID=087fac1d-02 etc...

to:

usb-storage.quirks=152d:0578:u console=serial0,115200 console=tty1 root=PARTUUID=087fac1d-02 

Doing this, after next boot, syslog will show something like:

Feb 28 20:19:12 idril kernel: [    2.085933] usb 2-1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice= 5.08
Feb 28 20:19:12 idril kernel: [    2.085980] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 28 20:19:12 idril kernel: [    2.086014] usb 2-1: Product: USB to ATA/ATAPI Bridge
Feb 28 20:19:12 idril kernel: [    2.086045] usb 2-1: Manufacturer: JMicron
Feb 28 20:19:12 idril kernel: [    2.086074] usb 2-1: SerialNumber: 0123456789ABCDEF
Feb 28 20:19:12 idril kernel: [    2.090111] usb 2-1: UAS is ignored for this device, using usb-storage instead
Feb 28 20:19:12 idril kernel: [    2.090255] usb 2-1: UAS is ignored for this device, using usb-storage instead
Feb 28 20:19:12 idril kernel: [    2.090294] usb-storage 2-1:1.0: USB Mass Storage device detected

This is surely not a solution, at best a quick workaround.

0

I believe this was being caused by a power issue. The SSD in question was inside a seagate USB3 enclosure that was powered by the USB3 cable. I switched to an old USB2 enclosure that I had laying around that has it's own power supply and the problem went away.

When I was taking the SSD out of the USB3 enclosure, I found a sticker on it that said it was rated at 5v 2 amp. 2 amp is more than the pi 4 can handle apparently.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.