2

I have a USB hard disk. When I plug it in onto my xhci_hcd bus then usually it won't be listed by lsusb. If I do udevadm monitor --kernel --property, no sign of the device being plugged in appears.

There are two things that will eventually succeed in making the device visible either in combination or alone:

  • shutting the lid (and thus sending the system into suspend to RAM state)
  • unbinding and rebinding the USB driver to the USB bus:

_

echo -n 0000:19:00.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
echo -n 0000:19:00.0 > /sys/bus/pci/drivers/xhci_hcd/bind

I would like to understand, how detection works, i.e. which layer is it, that is "malfunctioning" here and why?

As far as I know:

  1. the first step in the communication between device and host is that the device inserts a resistance into the electrical loop which makes the host (or the hub?), aware of the physical (electrical) presence of the device. Is this correct? Does the HW (the hub/the bus?) signal this electrical event (to the bus driver)? Should udevadm monitor --kernel --property show me this event? If not is there anything else that can show me this event on the host side?

  2. what happens next? Should this be visible in udevadm?

  3. the "transport layer" of the USB stack takes over and the host sends a USB control packet to the device, asking it for its Vendor and Product IDs. Who is responsible to do this? Is this already the bus driver software doing this or is this still in "hardware" (i.e. software on the laptop's USB hub/bus)? Should this be visible in udevadm?

  4. the host receives the answer from the device and now knows what VID/PID the device has. Does this necessarily mean that the device would be visible on lsusb at this point?

I have scoured the internets, but haven't found a "how does device (function) detection work with USB" document yet. Short of reading the 670+ pages of the USB specification - can anybody maybe tell me:

  • which steps above are executed by hardware (the hub and it's internal SW)?
  • at which point does the driver get notified (an event, interrupt, it polls or whatever)?
  • are there (better? more specialized?) tools that would be able to tell me earlier in the process what is going on (short of adding debug statements to the USB bus driver)?

FWIW:

  • the bus is a Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
  • and the device is a Bus 002 Device 002: ID 1e68:001b TrekStor GmbH & Co. KG DataStation maxi g.u drive
  • Debian kernel 3.16.0-4-amd64
  • 1
    Anything in dmesg when you plug in the USB harddisk? Does the harddisk have external power, or is it powered via USB? If the latter, it's possible it doesn't get enough power via USB. – dirkt Dec 16 '17 at 13:23
  • hi @dirkt, thanks a lot for replying. No trace in dmesg. The disk does have external power. Once it's recognized, making a backup onto it works well (that takes >1h), so I guess it's not a power problem. Though I have to say, my laptop has 4 ports, 3 of which are USB 2 and one is USB 3. If I connect the drive to the USB 3 port instead, then it is nearly impossible to finish the backup. There's always a write error at some point and the backup aborts due to the FS going read only. I guess that's due to the connecting cable not being good enough for USB 3 speeds, but I'm not sure. – Tomáš Pospíšek Dec 17 '17 at 21:48
  • This really starts to look like some hardware problem: cable (loose contact somewhere?), host controller, harddisk USB controller, or somehow a combination of them. "Normal" USB connections shouldn't behave this way. – dirkt Dec 17 '17 at 23:21
  • @dirkt - might be, that is speculation though at this point. That's why I'd be interested in knowing what happens at which point in the USB device detection process (that way I could say - this should have happened here, but didn't, so the problem is here or below.) – Tomáš Pospíšek Dec 19 '17 at 7:37
  • As it doesn't show up in dmesg or as kernel event, it happens very early: Either the new device is not detected at all, or USB enumeration fails/is never initiated. Things to test: Switch all involved components (cable, USB host, USB client), possibly in different combinations, see if anything changes. If it's a loose contact or broken cable, try to wiggle the cable in different places. Loose contacts can also happen inside the plugs (bad solder point). Have tail -f /var/log/syslog open, so you see the reaction. – dirkt Dec 19 '17 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.