I've been using Unraid for a few months with a 4 bay external USB enclosure and everything has been running fine. I recently upgraded to version 7.0.1 and Unraid is now crashing during a parity check. Most of the time it crashes within a minute or two, the longest I've had it run is 20 minutes. A SMART test of all drives has come back ok, so I don't think they're the problem.

 

I have syslog server set up to send logs to an instance of Graylog I have running, and I regularly get errors like the following:
 

sd 1:0:0:0: [sda] tag#16 CDB: opcode=0x88 88 00 00 00 00 00 01 13 91 98 00 00 04 00 00 0
sd 1:0:0:0: [sda] tag#15 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
sd 1:0:0:0: [sda] tag#15 CDB: opcode=0x88 88 00 00 00 00 00 01 13 8d 98 00 00 04 00 00 00
sd 1:0:0:0: [sda] tag#14 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
scsi host1: uas_eh_device_reset_handler start
usb 3-2: reset SuperSpeed USB device number 2 using xhci_hcd
scsi host1: uas_eh_device_reset_handler success

 

While this happens, the speed of the parity check completely drops and the temperature of some of my drives shows as *. If it reset successfully (as per the example above), it picks back up, but will eventually happen again. When it doesn't reset the device successfully, it crashes the whole machine. While these errors are happening, it maxes out the CPU at 100%.

 

I've tried setting this in my syslinux config, which matches the ID of my USB enclosure, but that hasn't helped.

usb_storage.quirks=174c:55aa:u

 

Everything seems to work fine up until I run a parity check. I only use Unraid for storage, so it's a pretty simple installation as Docker is disabled.

 

I've attached my diagnostics if anybody is free to help. 

 

Thank you very much.

unmox-diagnostics-20250315-0040.zip

Post the output from:

lsusb -vt

 

1 hour ago, JorgeB said:

Post the output from:

lsusb -vt

 

 

 

Here's the output, thank you
 

lsusb -vt
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
    ID 1d6b:0001 Linux Foundation 1.1 root hub
    |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        ID 0627:0001 Adomax Technology Co., Ltd
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        ID 048d:1172 Integrated Technology Express, Inc. Flash Drive
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 002: Dev 002, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
    |__ Port 003: Dev 003, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
    |__ Port 004: Dev 004, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
    |__ Port 005: Dev 005, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

 

9 hours ago, WazzleUK said:

usb_storage.quirks=174c:55aa:u

The lsusb output shows it's still using the UASP driver, but this should have worked, assuming it was added correctly and to the option you are using for boot, does it look like this:

 

 

 

 

 

51 minutes ago, JorgeB said:

The lsusb output shows it's still using the UASP driver, but this should have worked, assuming it was added correctly and to the option you are using for boot, does it look like this:

 

 

 

 

 

 

Wow, I can't believe I messed that up. I had it on a new line instead of on one line like that. The parity check has been running for 35 minutes without an error, so it looks like this is resolved now.

 

Thanks so much for your help, have a beer on me 

I have been getting similar issues since 7.0.1 during parity check and/or rebuild with an external USB enclosure with 3 HDDs.

 

The issue takes down the entire USB bus, and even the flash USB stick with unraid OS on it gets disconnected.

 

This is the bit of my logs where things clearly go downhill:

Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#15 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#15 CDB: opcode=0x88 88 00 00 00 00 01 39 91 8e 98 00 00 00 c8 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#14 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#14 CDB: opcode=0x88 88 00 00 00 00 01 39 91 8a 98 00 00 04 00 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#13 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#13 CDB: opcode=0x88 88 00 00 00 00 01 39 91 88 f0 00 00 01 a8 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#12 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#12 CDB: opcode=0x88 88 00 00 00 00 01 39 91 84 f0 00 00 04 00 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#11 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#11 CDB: opcode=0x88 88 00 00 00 00 01 39 91 79 28 00 00 04 00 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#10 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#10 CDB: opcode=0x88 88 00 00 00 00 01 39 91 81 30 00 00 03 c0 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#9 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#9 CDB: opcode=0x88 88 00 00 00 00 01 39 91 7f 20 00 00 02 10 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#8 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#8 CDB: opcode=0x88 88 00 00 00 00 01 39 91 7d 28 00 00 01 f8 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#7 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#7 CDB: opcode=0x88 88 00 00 00 00 01 39 91 78 d8 00 00 00 50 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#6 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#6 CDB: opcode=0x88 88 00 00 00 00 01 39 91 71 28 00 00 03 b0 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#5 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#5 CDB: opcode=0x88 88 00 00 00 00 01 39 91 6f 60 00 00 01 c8 00 00
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#4 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN 
Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#4 CDB: opcode=0x88 88 00 00 00 00 01 39 91 74 d8 00 00 04 00 00 00
Mar 21 00:12:06 Tower kernel: sd 2:0:0:0: [sdc] tag#17 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD IN 
Mar 21 00:12:06 Tower kernel: sd 2:0:0:0: [sdc] tag#17 CDB: opcode=0x85 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00
Mar 21 00:12:06 Tower kernel: scsi host2: uas_eh_device_reset_handler start
Mar 21 00:12:06 Tower kernel: usb 2-2.3.2: reset SuperSpeed Plus Gen 2x1 USB device number 5 using xhci_hcd
Mar 21 00:12:06 Tower kernel: scsi host2: uas_eh_device_reset_handler success
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN: TRB error for slot 9 ep 2 on endpoint
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN Event TRB for slot 9 ep 2 with no TDs queued?
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN: TRB error for slot 9 ep 2 on endpoint
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN Event TRB for slot 9 ep 2 with no TDs queued?
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd 
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work 
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work 
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work 
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work 
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work 
Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00
Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared

 

and this is my output from `lsusb -vt` command:

 

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 0bda:5420 Realtek Semiconductor Corp.
        |__ Port 003: Dev 004, If 0, Class=Hub, Driver=hub/4p, 480M
            ID 0bda:5420 Realtek Semiconductor Corp.
    |__ Port 006: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth
    |__ Port 006: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth
    |__ Port 007: Dev 009, If 0, Class=Mass Storage, Driver=uas, 480M
        ID 0781:5583 SanDisk Corp. Ultra Fit
    |__ Port 010: Dev 006, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
        ID 10c4:ea60 Silicon Labs CP210x UART Bridge
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 10000M
        ID 0bda:0420 Realtek Semiconductor Corp.
        |__ Port 003: Dev 003, If 0, Class=Hub, Driver=hub/4p, 10000M
            ID 0bda:0420 Realtek Semiconductor Corp.
            |__ Port 001: Dev 004, If 0, Class=Mass Storage, Driver=uas, 10000M
                ID 174c:235c ASMedia Technology Inc.
            |__ Port 002: Dev 005, If 0, Class=Mass Storage, Driver=uas, 10000M
                ID 174c:235c ASMedia Technology Inc.
            |__ Port 003: Dev 006, If 0, Class=Mass Storage, Driver=uas, 10000M
                ID 174c:235c ASMedia Technology Inc.
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub

 

tower-diagnostics-20250321-0917.zip

Edited March 21, 20251 yr by iLaurens

35 minutes ago, iLaurens said:

and this is my output from `lsusb -vt` command:

Add a quirk like the below, but with 174c:235c:u

 

57 minutes ago, JorgeB said:

Add a quirk like the below, but with 174c:235c:u

 

I added it now and giving it another go. Let's see if it solves the issue.

 

The enclosure is a terramaster d6-320 and it seems it also might have something to do with the usb controller not getting enough power by the looks of this thread. If the quirk doesn't fix it then i'll buy a new gen3.2 gen 2 USB C cable and powered usb hub. 

 

 

Edited March 21, 20251 yr by iLaurens

2 hours ago, iLaurens said:

If the quirk doesn't fix it then i'll buy a new gen3.2 gen 2 USB C cable and powered usb hub. 

If the issue only started with 7.0.x the quirk should resolve it, but it will keep using the older USB storage driver, possible, the new UASP driver would perform better, but stability is more important.

On 3/21/2025 at 1:13 PM, JorgeB said:

If the issue only started with 7.0.x the quirk should resolve it, but it will keep using the older USB storage driver, possible, the new UASP driver would perform better, but stability is more important.

The quirk did fix it, fortunately! Indeed stability is far more important than performance. If this performance benchmark is worth anything, it seems I only random read operations are beneficial. However since this is typically bulk storage for large files I don't think that really matters. 

Commenting here for posterity to say that I've also been suffering this issue. I'm a new Unraid user so I went through weeks of troubleshooting before I was able to finally narrow it down to the external USB enclosure causing my frequent crashes whenever large writes (particularly between drives) were underway. Nothing in any of the logs mentions the cause of the crash, and all of the usual UnRaid troubleshooting steps were fruitless.

After finally narrowing it down, I was able to consistently reproduce the crashes using the "unbalanced" plugin on the community apps store. I kick off a 500gb transfer between two drives in enclosures and the server consistently hard crashes after a hundred or so gigs. I did it five times to be sure it was reliably unreliable.

Googling led me to a number of unhelpful solutions until finally taking me to this thread, which contained the cure to my pain. I tried adding ``` usb_storage.quirks=174c:235c:u``` to the append in my boot config under the UnRAID boot drive UI and rebooted the system. Upon reboot I ran ```lsusb -t``` to verify the crashing drives now list "usb-storage" as their Driver, whereas beforehand it listed "uas".

I crossed my fingers and ran the "unbalanced" test again with 500gb and it completed successfully for the first time. I nearly wept.

for what its worth, my enclosure is the same as @iLaurens before me: the terramaster d6-320. I have it connected to the front USB3.1gen2 ports on a minipc using the cable that came with the device, and the thread @iLaurens linked above explains that my problem is likely due to insufficient power over the usb ports. In any case, the quirk works and that's good enough for me.

Thank you to everyone on the thread for your comments. This has been driving me insane.