You are not logged in.
So whenever I am in the middle of a larger file transfer (say from my /data partition to the drive using thunar's file transfer), the drive stops spinning and does not respond to any system commands. The blue power light is on on the HDD enclosure, but my only solution is to physically unplug it and plug it back in because commands like "eject" don't work because /dev/sdb is not present. Both the drive and my data partition use exFAT. It can happen during the transfer of any file. I get the error "Error Splicing File: Input/Output Error - Cannot Copy." Any ideas?
Last edited by swaplink (2018-03-26 20:42:06)
Offline
What kernel version? What dmesg output?
Offline
As loqs says, as a start the full dmesg output after you trigger the problem is going to be needed.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
What kernel version? What dmesg output?
My kernel is linux-hardened 4.15.12.a-1 (latest in repo extra). Here is dmesg output after the problem happened a couple times: pastebin.com/MctVJidC.
Offline
I would have preferred to see the dmesg output posted here inside code tags as this thread will stop being useful once the pastbin expires, but you are doing what the CoC says so no problem.
At first glance it seems the UAS driver might be involved, can you also post the output of 'lsusb -t' with the external disk plugged in? That should help confirm which driver is in use. Then we can go from there.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I would have preferred to see the dmesg output posted here inside code tags as this thread will stop being useful once the pastbin expires, but you are doing what the CoC says so no problem.
At first glance it seems the UAS driver might be involved, can you also post the output of 'lsusb -t' with the external disk plugged in? That should help confirm which driver is in use. Then we can go from there.
Sorry, I put it in the pastebin because it was extremely long. It should be set to never expire. Anyway, here is the output of 'lusb -t':
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 2: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 5: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 5: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 8: Dev 4, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M
|__ Port 10: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
Offline
Check smartctl -x output for the drive (if the command succeeds) and if possible use a different USB<>SATA bridge (or change the enclosure) to rule out a disk defect (mileage may vary, depending on the manufacturer of the disk). It's also not unusual for USB<>SATA bridges to be garbage and have hardware design issues or firmware bugs. That fact that the hickup (only?) happens when putting the bridge under high load points into this direction.
Speaking of which: I'm also seeing that the external HDD uses the xhci driver (USB3). Try connecting the drive to a USB2 port instead or disabling USB3 in the BIOS/UEFI settings screen for the port or force the ahci driver for the device in some way; I have one external drive in my collection which exposeses similarly erratic behaviour on USB3 but works fine with USB2 – this is entirely a problem with the disk enclosure/USB<>SATA bridge in question since the drive will work fine over USB3 when using a different USB3<>SATA bridge.
Last edited by jsoy9pQbYVNu5nfU (2018-03-31 11:06:24)
Offline
I assume the first two lines correspond to the external hard disk. As I suspected the UAS is the one being used. You can force the UAS to not be used for that drive. Create a new file in /etc/udev/rules.d ending with .rules, for example nouas.rules with:
options usb-storage quirks=2109:0715:u
Then disconnect and reconnect the external disk and recheck the 'lsusb -t' output and see if usb-storage is used instead of UAS. Then try replicating the problem.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
My bet is on power saving and/or USB autosuspend.
Do you use anything like tlp/laptop-mode-tools/powertop autotune or a big fat DE that brings its own power saving?
If not (if yes, skip that to rule out impact from there ;-) try passing "usbcore.autosuspend=-1" to the kernel parameters, you can also configure/check this at runtime per-device,
cat /sys/bus/usb/devices/usb*/power/autosuspend*
Online
The OP does say the problem happens in the middle of large transfers so power saving is most probably not be the cause but still worth checking.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I had a similar problem a while back where my external drive would just shut down at random times, often during a transfer. It turned out that it wasn't getting enough power from the USB port I had it plugged into, so I tried one of the USB3 ports on the back of my computer rather than the convenient ones on the front and the problem went away. Though I don't know if it is the same problem you are facing, it can't hurt to try a different port if possible.
Offline
Doesn't hurt to try another port but it should be connected to a usb3 port already because it is connected at a 5000M speed.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline