40

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?

Improve this question
7
  • 3
    Making RAID from USB drives does not sound like good idea. RAID is all about reliably having all your drives, and USB is all about hot plugging and unplugging devices. Since you are using RAID-1, it is not so bad, but it is not very good idea either.
    – mvp
    Commented Nov 3, 2013 at 10:28
  • 2
    There is nothing wrong with using USB devices in RAID configuration. It is a perfectly sound idea, all the more so when one considers that it is a home computer, not an enterprise server. You could argue USB throughput limitations, but that is not a concern for me personally. This raid is a lazy approach to backup solution more than anything else.
    – ILIV
    Commented Nov 3, 2013 at 14:38
  • 2
    You indicated that your drives are connected to USB ports of notebook. Say what you want, but this is simply time bomb waiting to go off. Also, if your devices are USB3, kernel must use xhci_hcd. If it is using ehci_hcd, that means your devices are running at USB2 speeds.
    – mvp
    Commented Nov 3, 2013 at 16:30
  • 2
    Because one day your cat (or more likely yourself, considering it is connected to laptop) will pull the cable. Or, USB port will burn out. Or something else will happen (like your spurious USB resets), and your RAID array will be degraded. I have seen more than once when degraded RAID array ultimately led to full data loss.
    – mvp
    Commented Nov 4, 2013 at 6:47
  • 4
    I see, next time, please, try to come up with real reasons for calling something a time bomb. Just for the record, I do not have a cat, or any other pet, I have never pulled cables, this notebook has remained stationery for a couple of years now, chances of having USB ports burn out are about equal to a chance of having direct connection becoming broken, "something else" is funny, could happen even to most thoroughly configured and installed enterprise server. So, stop being so paranoid. This is RAID-1. Having 2 disks go out at the same time, is very unlikely. This is a solid solution. Period.
    – ILIV
    Commented Nov 4, 2013 at 10:12

2 Answers 2

Reset to default
48
+50

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.

Improve this answer
3
  • Super summary, thank you! Some additional sources would be cool.
    – Christian Benke
    Commented Oct 14, 2017 at 13:46
  • 1
    Do you know if that is possible to increase the number of retries done by ehci_hcd module? Or is it possible to force ohci_hcd for a particular device (e.g. /dev/sda is handled by ehci_hcd and "problematic" /dev/sdb is handled by ohci_hcd)?
    – dma_k
    Commented Dec 15, 2017 at 9:37
  • 2
    I've made these go away with a better cable. YMMV.
    – Leopd
    Commented Jul 6, 2021 at 22:28
9

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:

  1. Replace hardware: In most cases you need to replace the motherboard.
  2. Remove ehci_hcd driver
  3. 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?

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .