Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#69646 - External USB Drives causing SCSI Bus to continuously reset
Attached to Project:
Arch Linux
Opened by Justin Shepherd (justin-shepherd) - Monday, 15 February 2021, 09:08 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 19 September 2021, 08:57 GMT
Opened by Justin Shepherd (justin-shepherd) - Monday, 15 February 2021, 09:08 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 19 September 2021, 08:57 GMT
|
DetailsContext of issue
------- I've been using a Seagate 4TB SRD00F2 [Expansion Desktop Drive] USB External plugged in to my Desktop and occasionally it appears that the SCSI bus just resets after a period of time. This occurs under small and large workloads and can be from anywhere between minutes and hours - Use case eg: - Small but infrequent read/writes - Plex Media Server Metadata Scanning and Storage (Large library of TV Shows and Movies) - Large writes - Movies & TV Shows being saved to the HDD via NFS or SFTP/SSH Some solutions around the internet have suggested disabling UAS for the particular USB. In my case options usb-storage quirks=0bc2:02322:u, however, this only seems to delay the inevitable and the device still resets. dmesg when issue/reset occurs reports (desktop with UAS disabled) [ 1711.783246] usb 6-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [ 1711.796978] sd 8:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s [ 1711.796982] sd 8:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 3e 11 4b 58 00 08 00 00 [ 1711.796985] blk_update_request: I/O error, dev sdc, sector 1041320792 op 0x0:(READ) flags 0x80700 phys_seg 33 prio class 0 lsusb -v -d 0bc2:3320 https://pastebin.com/u0AH570g Testing ------- Since then I've tried the following boards: Desktop (both UAS enabled/disabled) - Not working OS: Arch Linux Kernel: 5.10.16.arch1-1 MOBO: X570 I AORUS PRO WIFI (rev. 1.0) Intel NUC 1 (both UAS enabled/disabled) - Not working Model: NUC8i5BEH OS: Proxmox Kernel: Linux pve 5.4.78-2-pve Intel NUC 2 (default configuration with continuous uptime of 2 days for testing) - Working Model: NUC8i5BEH OS: VMWare ESXi 7.0 U1 Kernel: vmkernel Conclusions ------- I'm suspecting that not all manufacturers care enough about proper implementation of xhci_hcd support for full-speed devices, but I'm definitely not an expert in this matter, so I'm just judging by my observations and some research. This particular USB 3 enclosure was made sometime in 2012. Additional Notes ------- Also reported here https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1584557 - Seems to be a known issue for certain enclosures (not specific to just Seagate as shown from the comments) |
This task depends upon
Closed by Andreas Radke (AndyRTR)
Sunday, 19 September 2021, 08:57 GMT
Reason for closing: None
Additional comments about closing: Some fix is available adding a device quirk see launchpad report.
Sunday, 19 September 2021, 08:57 GMT
Reason for closing: None
Additional comments about closing: Some fix is available adding a device quirk see launchpad report.
Comment by Andreas Radke (AndyRTR) -
Monday, 15 February 2021, 12:35 GMT
There's probably not much we can do at distribution level here.
Comment by Justin Shepherd (justin-shepherd) -
Monday, 15 February 2021, 18:27 GMT
Absolutely understand. I guess this is more for visibility if anything - hoping our wonderful devs here at Arch might have a set of fresh eyes/insight on it. That being said, I'm happy to close this off if there's not really much we can do. The alternative for me which I've already done here is shucked the drive and put it into a docking station with a recent ASMedia Chipset with great UASP support (ASM1153E) - This presented no issues whatsoever. Thanks Andreas for initially taking a look here.