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

_______________________________________________
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to