[Bug 1203718] New: USB/UAS device resets happening with external SATA III 6G HDD enclosure
http://bugzilla.opensuse.org/show_bug.cgi?id=1203718 Bug ID: 1203718 Summary: USB/UAS device resets happening with external SATA III 6G HDD enclosure Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: eecdc3.opensuse@coders-haven.net QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Dear openSUSE community, I am unfortunately experiencing frequent USB/UAS device resets with my new FANTEC DB-ALU31, which according to its product name (ASM235) is using an ASM235CM chipset from ASMedia. The relevant output from `lsusb -vt` is as follows: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M ID 1d6b:0003 Linux Foundation 3.0 root hub |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 10000M ID 0bda:0423 Realtek Semiconductor Corp. |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=uas, 10000M 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 The device is detected and can be mounted without issues but during regular use it may slow down or freeze programs that try to access it with output in /var/log/messages looking like: 2022-09-24T10:16:25.112084+02:00 kernel: [ 6192.198327][T26507] sd 0:0:0:0: [sda] tag#14 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT 2022-09-24T10:16:25.112102+02:00 kernel: [ 6192.198336][T26507] sd 0:0:0:0: [sda] tag#14 CDB: Write(16) 8a 00 00 00 00 02 46 07 2f 5f 00 00 00 18 00 00 2022-09-24T10:16:25.112104+02:00 kernel: [ 6192.198492][T26507] sd 0:0:0:0: [sda] tag#13 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT 2022-09-24T10:16:25.112106+02:00 kernel: [ 6192.198498][T26507] sd 0:0:0:0: [sda] tag#13 CDB: Write(16) 8a 00 00 00 00 02 46 07 2f 37 00 00 00 28 00 00 2022-09-24T10:16:25.112108+02:00 kernel: [ 6192.198644][T26507] sd 0:0:0:0: [sda] tag#12 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT 2022-09-24T10:16:25.112109+02:00 kernel: [ 6192.198650][T26507] sd 0:0:0:0: [sda] tag#12 CDB: Write(16) 8a 00 00 00 00 02 46 07 2f 17 00 00 00 20 00 00 2022-09-24T10:16:25.112111+02:00 kernel: [ 6192.198800][T26507] sd 0:0:0:0: [sda] tag#11 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT 2022-09-24T10:16:25.112126+02:00 kernel: [ 6192.198806][T26507] sd 0:0:0:0: [sda] tag#11 CDB: Write(16) 8a 00 00 00 00 02 46 07 2e f7 00 00 00 20 00 00 2022-09-24T10:16:25.112127+02:00 kernel: [ 6192.198943][T26507] sd 0:0:0:0: [sda] tag#10 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT 2022-09-24T10:16:25.112128+02:00 kernel: [ 6192.198949][T26507] sd 0:0:0:0: [sda] tag#10 CDB: Write(16) 8a 00 00 00 00 02 46 07 2e e7 00 00 00 10 00 00 2022-09-24T10:16:25.112129+02:00 kernel: [ 6192.199094][T26507] sd 0:0:0:0: [sda] tag#9 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT 2022-09-24T10:16:25.112130+02:00 kernel: [ 6192.199101][T26507] sd 0:0:0:0: [sda] tag#9 CDB: Write(16) 8a 00 00 00 00 02 46 07 2e c7 00 00 00 20 00 00 2022-09-24T10:16:25.112130+02:00 kernel: [ 6192.199278][T26507] sd 0:0:0:0: [sda] tag#8 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT 2022-09-24T10:16:25.112131+02:00 kernel: [ 6192.199285][T26507] sd 0:0:0:0: [sda] tag#8 CDB: Write(16) 8a 00 00 00 00 02 46 07 2e bf 00 00 00 08 00 00 2022-09-24T10:16:25.112133+02:00 kernel: [ 6192.199393][T26507] sd 0:0:0:0: [sda] tag#7 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN 2022-09-24T10:16:25.112134+02:00 kernel: [ 6192.199397][T26507] sd 0:0:0:0: [sda] tag#7 CDB: Read(16) 88 00 00 00 00 02 06 96 c9 d8 00 00 00 07 00 00 2022-09-24T10:16:25.112135+02:00 kernel: [ 6192.200510][T26507] sd 0:0:0:0: [sda] tag#6 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN 2022-09-24T10:16:25.112136+02:00 kernel: [ 6192.200513][T26507] sd 0:0:0:0: [sda] tag#6 CDB: Read(16) 88 00 00 00 00 02 06 96 c5 df 00 00 03 f9 00 00 2022-09-24T10:16:25.116046+02:00 kernel: [ 6192.204015][T26507] sd 0:0:0:0: [sda] tag#5 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN 2022-09-24T10:16:25.116063+02:00 kernel: [ 6192.204022][T26507] sd 0:0:0:0: [sda] tag#5 CDB: Read(16) 88 00 00 00 00 02 06 96 cd d8 00 00 00 07 00 00 2022-09-24T10:16:25.120123+02:00 kernel: [ 6192.207464][T26507] sd 0:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN 2022-09-24T10:16:25.120131+02:00 kernel: [ 6192.207472][T26507] sd 0:0:0:0: [sda] tag#4 CDB: Read(16) 88 00 00 00 00 02 06 96 c9 df 00 00 03 f9 00 00 2022-09-24T10:16:25.148038+02:00 kernel: [ 6192.234339][T25745] scsi host0: uas_eh_device_reset_handler start 2022-09-24T10:16:25.228043+02:00 kernel: [ 6192.314872][T25745] usb 4-1.3: reset SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd 2022-09-24T10:16:25.248055+02:00 kernel: [ 6192.337003][T25745] scsi host0: uas_eh_device_reset_handler success After I added a quirk to /etc/modprobe.d/ via 'options usb-storage quirks=174c:55aa:u' to ignore UASP support, the occurrance rate of the resets seems to have reduced but they still occur: 2022-09-24T10:52:44.552258+02:00 kernel: [ 545.639051][ T3616] usb 4-1.3: reset SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd 2022-09-24T10:52:44.572116+02:00 kernel: [ 545.660702][ C1] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s 2022-09-24T10:52:44.572139+02:00 kernel: [ 545.660715][ C1] sd 0:0:0:0: [sda] tag#0 CDB: Read(16) 88 00 00 00 00 01 f4 f4 1a 37 00 00 07 f9 00 00 2022-09-24T10:52:44.572143+02:00 kernel: [ 545.660719][ C1] blk_update_request: I/O error, dev sda, sector 8404605495 op 0x0:(READ) flags 0x84700 phys_seg 29 prio class 0 I am using an up-to-date installation of openSUSE Leap 15.4 running Linux 5.14.21-150400.24.21-default and any help debugging this further will be appreciated. (The fact that the device string shown by `lsusb` makes no mention of the updated chipset leads me to believe that support for this chipset has not hit the kernel yet, but I am not familiar with the USB kernel driver nor with debugging it.) Note that I have already checked the S.M.A.R.T. attributes and there does not appear to be a problem with the device itself. I can also use the device without problems with Windows 10 21H2, even after extended use. Thanks in advance for your assistance! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1203718 http://bugzilla.opensuse.org/show_bug.cgi?id=1203718#c1 --- Comment #1 from Anonymous User <eecdc3.opensuse@coders-haven.net> --- While mentioned in the `lsusb` output, I did want to mention that the enclosure is not connected directly with my laptop (a HP Elitebook 1040 G4) but via an USB 3.2 Gen 2 hub with a Realtek RTS5423 chipset from Delock, art. no. 63261. (I am only mentioning this for completeness, not that I'd expect that something is wrong with it.) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1203718 http://bugzilla.opensuse.org/show_bug.cgi?id=1203718#c2 --- Comment #2 from Anonymous User <eecdc3.opensuse@coders-haven.net> --- Well, it turns out my last comment aged badly: I have just repeated my test procedure (essentially verifying one of my borg archives) in various configurations with the following results: 1. When I connect my external case to my laptop's USB 3.2 Gen 1 port, both usb-storage and uas will not have to reset the device. 2. When I connect my external case to my laptop's Thunderbolt 3 port, which falls back to USB 3.2 Gen 2, there are no device resets when using uas either (and I skipped testing usb-storage). 3. Only when I connect my external case via my USB 3.2 Gen 2 hub from Delock, see my above comment, to my laptop's Thunderbolt 3 port, both usb-storage and uas will trigger the device resets reported above. So I guess this is either a problem with the hub itself or with this particular combination of hub and external case. Unfortunately, I am not sure how I can proceed to help with resolving the observed issues when using the hub there certainly were no messages in /var/log/messages hinting at the hub itself. The only discernible difference is that while the external case does not support USB power delivery (and has to be powered via an AC adapter), the hub does support it. Can this interfere with the packets received by the usb-storage and uas drivers? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1203718 http://bugzilla.opensuse.org/show_bug.cgi?id=1203718#c3 --- Comment #3 from Anonymous User <eecdc3.opensuse@coders-haven.net> --- And while I was re-testing the third configuration a new error pattern has appeared, this time during the device reset it seems: 2022-09-25T14:24:36.744111+02:00 kernel: [10697.830332][ T9684] scsi host0: uas_eh_device_reset_handler start 2022-09-25T14:24:41.816103+02:00 kernel: [10702.902351][ T9684] usb 4-1.3: Disable of device-initiated U1 failed. 2022-09-25T14:24:46.936098+02:00 kernel: [10708.022435][ T9684] usb 4-1.3: Disable of device-initiated U2 failed. 2022-09-25T14:24:47.016092+02:00 kernel: [10708.102722][ T9684] usb 4-1.3: reset SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd 2022-09-25T14:24:47.036031+02:00 kernel: [10708.125045][ T9684] scsi host0: uas_eh_device_reset_handler success -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1203718 http://bugzilla.opensuse.org/show_bug.cgi?id=1203718#c4 --- Comment #4 from Anonymous User <eecdc3.opensuse@coders-haven.net> --- While I don't have another USB 3.2 Gen 2 hub (and I don't even know if there are any that don't use the same Realtek chipset), I do have an old USB 3.0 hub from Delock, art. no. 62485, which uses a VIA Lab VL813 chipset, and have found that I am not experiencing any resets when using this hub instead. While I can use this hub in the mean time, I would appreciate it if I could also get my external enclosure to work with the more up-to-date USB 3.2 Gen 2 hub. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1203718 http://bugzilla.opensuse.org/show_bug.cgi?id=1203718#c6 Anonymous User <eecdc3.opensuse@coders-haven.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(eecdc3.opensuse@c | |oders-haven.net) | --- Comment #6 from Anonymous User <eecdc3.opensuse@coders-haven.net> --- Please note that the problematic device in this issue is technically a USB hub, not a docking station. The manufacturer unfortunately does not assign easily searchable product names, so I posted the article number in comment #1 instead. With this you can easily find the details on the manufacturer's website: https://www.delock.de/produkt/63261/merkmale.html?setLanguage=en. Both my laptop and of course also my external hard drive enclosure were connected to AC power while I was conducting my tests (and when I first observed the issue). I am assuming that you are asking because you suspect that the USB hub is entering a power saving mode when it shouldn't? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1203718 http://bugzilla.opensuse.org/show_bug.cgi?id=1203718#c8 --- Comment #8 from Anonymous User <eecdc3.opensuse@coders-haven.net> --- I have added usbcore.autosuspend=-1 to my command-line, rebooted, and verified via `cat /sys/module/usbcore/parameters/autosuspend` that it was indeed set globally to -1. When I re-ran my test the device resets were still occurring. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com