3

My external HDD dock require a frustrating sequence for mounting where plugging the usb cable must be the last step (ie insert HDD, power on, plug-in).

When I do this it works perfectly, but the cable is not very accessible, and I fear that frequent plug/unplug will eventually damage it.

So I tried to power-on the device while leaving the usb cable plugged. Sometimes it works and sometimes it doesn't. When it does not work I get this message (dmesg):

[372734.412683] xhci_hcd 0000:00:14.0: Command completion event does not match command
[372734.412686] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[372739.622686] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[372739.826432] usb 3-5: device not accepting address 21, error -62

A lsusb -v gives:

Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         3 
  bMaxPacketSize0         9
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0003 3.0 root hub
  bcdDevice            4.02
  iManufacturer           3 Linux 4.2.0-0.bpo.1-amd64 xhci-hcd
  iProduct                2 xHCI Host Controller
  iSerial                 1 0000:00:14.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           31
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
        bMaxBurst               0
Hub Descriptor:
  bLength              12
  bDescriptorType      42
  nNbrPorts             6
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
  bPwrOn2PwrGood       10 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  bHubDecLat          0.0 micro seconds
  wHubDelay             0 nano seconds
  DeviceRemovable    0x00
 Hub Port Status:
   Port 1: 0000.02a0 5Gbps power Rx.Detect
   Port 2: 0000.02a0 5Gbps power Rx.Detect
   Port 3: 0000.02a0 5Gbps power Rx.Detect
   Port 4: 0000.02a0 5Gbps power Rx.Detect
   Port 5: 0000.02e0 5Gbps power Polling
   Port 6: 0000.02a0 5Gbps power Rx.Detect

so if I understand correctly there is some error within an internal usb hub.

So I wonder if there is a way to simulate some kind of reset that would make the device to register again, without manipulating the usb cable.

This could also be helpful to remotely mount the device for example.

Thanks

user2245644
  • 53

2 Answers2

1

This is a bit old, but I just needed the answer and found it elsewhere.

First, copy your hub device name from error messages. In your case, 0000:00:14.0

Then, as root, do the following:

echo 0000:00:14.0 >> /sys/bus/pci/drivers/xhci_hcd/unbind
echo 0000:00:14.0 >> /sys/bus/pci/drivers/xhci_hcd/bind

And presto: The hub is reset and you can continue using.

I've been dealing with this bug for some years now. I'm not sure if it is a kernel issue, or a hardware issue (my main suspicion). But at least now I don't need to reboot just to reset the USB hub.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
Jonny
  • 111
0

The closest to a real unplug and replug is definitively not:

  • unbind + bind (i.e. via /sys/bus/usb/devices/.../driver/bind)
  • usbreset, which launches ioctl() with USBDEVFS_RESET
  • neither ioctl() with USBDEVFS_(DIS)CONNECT

because the kernel messages do not look the same as a real physical replug.

What looks indistinguishable from real re-plug in the kernel log is:

  • the /sys/bus/usb/devices/.../port/disable interface
  • write 1 into that file to disable
  • remember the controller based location of that interface with pwd -P
  • or read this long answer for more details and examples for re-enabling the device

It might be that full port control does not work that good everywhere, because some hardware can definitively not disable 5V power to the USB ports. I tested some random ports on an old office PC and an (also old) office monitor with USB hub: worked great.

Robert Siemer
  • 2,081