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:
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 --propertyshow me this event? If not is there anything else that can show me this event on the host side?what happens next? Should this be visible in
udevadm?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?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
lsusbat 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.udrive - Debian kernel 3.16.0-4-amd64
dmesgwhen 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.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.dmesgor 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). Havetail -f /var/log/syslogopen, so you see the reaction.