Re: [tlug] USB HDD Startup

["Jens John" <lists@example.com>]

On Mon, 23 Mar 2020, at 17:13, CL wrote:
> 5. Can anyone think of a reason for this behavior?

Without a full dmesg (where any interesting errors from the USB and I/O would go) from all scenarios & device information, it's impossible to tell exactly. Without the dmesg, it's also impossible to know if there were I/O errors that led to data corruption, of if Linux had some trouble with performing device I/O. These are a few vectors along which I've had issues with USB drives which, in SMART terms, were completely fine:

  * USB / client-side: A lot of cheap USB<>SATA bridges are not worth their silicon. Firmwares are often buggy; especially USB3 bridges in cheapish external hard drive cases used to be almost always a 50% hit and miss when USB2 still used to be the most deployed variant. On USB, all devices participating must behave reasonably well in order to make topologies work reliably. Linux has a lot of quirks for broken USB clients in the kernel. There may be differences in Windows vs Linux USB driver signalling which the one or other bridge might handle not so well, esp. if vendors have a crappy firmware to begin with and test only on Windows. Arguably this is less the case nowadays. You could try and put all devices on physically different USB controllers, if you have that many. You can tell by the bus number in lsusb --tree output. For example, on my laptop:

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M
    |__ Port 6: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 12M
    |__ Port 8: Dev 26, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 8: Dev 26, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
        |__ Port 5: Dev 3, If 0, Class=Chip/SmartCard, Driver=, 12M

you can see that I have 3 USB controllers, 2 with xhci driver (USB3) and 1 with USB2 support only. Most mainboards should have more than 1.

  * USB / controller-side: Likewise, Linux xhci  / USB driver could make some problems in the past, esp. in combination with certain hardware. You could try disabling USB3 in the motherboard BIOS/UEFI settings (deactivating the controller, most laptops and mainboards have such an option even today) or blacklisting the xhci modules in Linux; this will make Linux attach the ehci/USB2 driver to the devices, which might change the device behaviour in your favour. Of course, dramatically lower speeds are the consequence. Still, for over a year on my laptop, this was the only way to drive USB3 hard drives in a stable manner (back in Linux 3.x/early 4.x times - my laptop apparently wasn't well supported). You can check the attached driver from lsusb --tree output.

  * USB power management: Kernel versions after 3.x try much harder to manage periphal power states. Review the USB controller power state in /sysfs or better the CLI tool powertop (could be Intel only), where you'll also be able to toggle controller power states. It could be that the USB controller suspends and doesn't wake up correctly, leading to unpredictable errors. For example, the device may be attached as a block device (check lsblk and/or dmesg) yet Linux will show I/O errors in dmesg when trying to write to it, or any partition mounted from it. A sign that something's up with power management is the observation that after a computer/laptop suspend&wake cycle, USB ports mysteriously stop working while after a fresh reboot everything is fine.

In short, the only way to rule out USB issues completely is to take the disk out of its case and connect it directly to an SATA/IDE port. USB is pretty complex, and many things can go wrong.