USB devices sometimes not seen at boot time

[Hans Petter Selasky]

On 06/29/17 21:46, Matthias Apitz wrote:
> 
> Hello,
> 
> I have the problem that on my netbook (an Acer C720) sometimes the USB
> devices are not seen at boot time while the bus is probed. I filed an
> issue as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220127 which
> did not got any attention so far.
> 
> Meanwhile I was trying to find the rule for the problem and have
> investigated the 'dmesg' output for any "good" boot (i.e. the devices
> was seen) and compared with "bad" boot (when the device was not seen).
> There is a clear dependency of the order the USB bus is probed:
> 
> This is from a good one:
> 
> # egrep 'uhub|ugen' dmesg-20170628-202601-good.txt
> ugen0.1: <0x8086 XHCI root HUB> at usbus0
> ugen1.1: <Intel EHCI root HUB> at usbus1
> uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
> uhub0: 13 ports with 13 removable, self powered
> uhub1: 2 ports with 2 removable, self powered
> ugen0.2: <Identiv uTrust 3512 SAM slot Token> at usbus0
> ugen0.3: <SunplusIT Inc HD WebCam> at usbus0
> ugen0.4: <vendor 0x0489 product 0xe056> at usbus0
> 
> and this is from a bad one:
> 
> # egrep 'uhub|ugen' dmesg-20170628-202351-bad.txt
> ugen1.1: <Intel EHCI root HUB> at usbus1
> ugen0.1: <0x8086 XHCI root HUB> at usbus0
> uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
> uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> uhub1: 13 ports with 13 removable, self powered
> uhub0: 2 ports with 2 removable, self powered
> ugen1.2: <vendor 0x8087 product 0x8000> at usbus1
> uhub2 on uhub0
> uhub2: <vendor 0x8087 product 0x8000, class 9/0, rev 2.00/0.04, addr 2> on usbus1
> uhub2: 8 ports with 8 removable, self powered
> 
> The device in question it the "Identiv uTrust 3512 SAM slot Token" and
> the rule is: When XHCI is probed as ugen0.1 and later as uhub0, all is
> fine; else it fails.
> 
> Any ideas on this?  What makes the boot differ in this order?
> 

Hi,

USB explores different root HUBs ugen0.1, ugenX.1 and so on in parallell 
and not serial. Maybe a race or electrical issue is causing the order to 
fail. You can try compiling a kernel without USB support and loading 
xhci, ehci, ohci and uhci by a script using kldload. Alternate the 
loading order.

--HPS