What are USB device resets?
I have this brand-new software RAID-1 built with two WD Elements external USB drives, and I can see that Linux repeats the following message quite a bit:
...
[302148.036912] usb 1-3.1: reset high-speed USB device number 19 using ehci_hcd
[302153.052029] usb 1-3.3: reset high-speed USB device number 20 using ehci_hcd
[302186.031481] usb 1-3.3: reset high-speed USB device number 20 using ehci_hcd
[302217.050210] usb 1-3.3: reset high-speed USB device number 20 using ehci_hcd
[302281.043543] usb 1-3.3: reset high-speed USB device number 20 using ehci_hcd
[302312.090158] usb 1-3.3: reset high-speed USB device number 20 using ehci_hcd
[302351.076851] usb 1-3.1: reset high-speed USB device number 19 using ehci_hcd
...
So, what does it say? Is this normal? Is this a problem that I should try to fix?
Update
Actually, these messages are not for the drives that I thought they were. I have a bunch of other USB drives connected to this computer via a USB hub as well. Anyway, my question is basically what does this message mean in plain English?
Let me try.
Literally the message says that Linux USB stack has issued "USB_RESET" to your particular device (devices #19 and #20, whatever they are). The error seems to occur once per 10-30 seconds. After reset, the log should have fresh enumeration messages, since USB reset will force the connected device into "default state". Looks like verbosity of your log is very reduced.
Resetting a USB device in the middle of operation is a pretty drastic situation. The controller resorts to this "port" reset if it encounters "transaction error". Transaction error occurs when the link does not complete all required phases of USB transaction, or has a CRC error. In normal USB the EHCI controller will automatically re-try the failing transaction (typical maximum 3 times), and then will set an XACT_ERROR interrupt. Statistically, by error theory, if a link does not respond properly to three attempts in a row, there is something wrong with the particular USB segment, mostly electrically. So the transaction error is considered as fatal, and software tries to recover the link. If tree-four attempts to recover the link fail, the host considers this port as dead, and quits.
In Linux however, someone has decided that 3 theoretical attempts is not enough, and Linux software performs additional 32 (thirty-two) attempts, making it 96 (!!!) total. If the hardware link happens to be electrically marginal, the 96 attempts might succeed in 99.99% of the time. Linux software gurus claim that this helps to improve operability of questionable devices/cables. In essence, this technique hides a serious problem with this particular USB connection, which does not help users in long run.
The problem could be in marginal voltage (VBUS) supply to the drives, or VBUS glitches, or signal degradation on signal wires. I would try extremely short high-quality certified cables first, and check if the statistics of error changes.
This error is described in the article Linux: Reset High Speed USB Device Using ehci_hcd Error and Solution :
This error indicates that USB 2.0 may not function on your system, or may function only at USB 1.1 speeds. To fix this problem:
- Replace hardware: In most cases you need to replace the motherboard.
- Remove ehci_hcd driver
- Disable ehci_hcd drive USB 2.0 interface and use it as USB 1.1. In short disable the ehci_hcd.
If you do not wish to replace the motherboard,
to remove the ehci_hcd Driver edit the file /etc/modprobe.d/blacklist.conf
and add the line :
blacklist ehci_hcd
Finally, use the mkinitrd script to construct a directory structure that can serve as an initrd root file system without ehci_hcd:
# mkinitrd -o /boot/initrd.$(uname -r).img $(uname -r)
Reboot as test.
An article with similar instructions is : Why is the error "kernel: usb 1-2.2: reset high speed USB device using ehci_hcd and address 6" written to the /var/log/messages file?