Kernel settings for USB 1-10: reset high-speed USB device X with xhci_hcd
Kernel settings for USB 1-10: reset high-speed USB device X with xhci_hcd
Hello, I see your system logs are getting a lot of this message. Everything appears normal—docker, vms, shares, etc.—and you tried changing USB ports on the motherboard without any issues. It doesn’t seem to be related to your flash drive. You’ve been running the server since November 2018, so it’s possible other factors are at play. Let me know if you’d like further help!
It suggests a power or cabling issue rather than a drive problem—it’s the USB link being reset, likely due to a faulty connection at the USB-to-SATA interface on the device. Try another cable, and if the drive lacks external power, use a "two-in-one" adapter for additional voltage. It might be the controller failing, but data loss would only occur during write operations.
It might help if you added an internal USB 2.0 header adapter to USB A.
It seems like you're dealing with a unique setup where everything is on a single PCB. I need to rule out that particular USB controller from your motherboard as the cause. Try using another USB device so it's clear which one is connected. Run `lsusb -t` in the terminal to see which devices are linked to each root hub. Plug the new device in and repeat the check, testing different ports until you identify a different hub. Once you find the correct port, move the thumb drive there and observe its behavior. If it works fine, you can copy the data using dd. Searching for "dd copy usb thumb drive" will provide helpful instructions.
I disconnected the front panel USB header (card reader) and the reset high-speed USB device notification stopped. Could you provide any clues about what might have triggered this? No devices were connected to the front panel readers. Appreciate your assistance.
It seems there could be several issues with the cabling and connections. Perhaps the shielding or construction isn’t adequate, cables are running near a noisy fan, there might be a faulty filter cap, silicon defects or debris could be present on the front panel, or even an improperly routed cable length causing resonance effects at the operating frequency. All these scenarios can occur randomly, but statistically they’re plausible. From a physics and electrical engineering standpoint, it’s reasonable to consider these possibilities as valid explanations.