Re: USB devices sometimes not seen at boot time
El día jueves, junio 29, 2017 a las 11:26:48p. m. +0200, Hans Petter Selasky escribió: > > # egrep 'uhub|ugen' dmesg-20170628-202601-good.txt > > ugen0.1: <0x8086 XHCI root HUB> at usbus0 > > ugen1.1: at usbus1 > > uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > > uhub1: on usbus1 > > uhub0: 13 ports with 13 removable, self powered > > uhub1: 2 ports with 2 removable, self powered > > ugen0.2: at usbus0 > > ugen0.3: at usbus0 > > ugen0.4: at usbus0 > > > > and this is from a bad one: > > > > # egrep 'uhub|ugen' dmesg-20170628-202351-bad.txt > > ugen1.1: at usbus1 > > ugen0.1: <0x8086 XHCI root HUB> at usbus0 > > uhub0: 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: at usbus1 > > uhub2 on uhub0 > > uhub2: 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. Hi, Thanks for the hint. I disabled the three entries for uhci, ohci and ehci: # USB support options USB_DEBUG # enable debug msgs # deviceuhci# UHCI PCI->USB interface # deviceohci# OHCI PCI->USB interface # deviceehci# EHCI PCI->USB interface (USB 2.0) device xhci# XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) device ukbd# Keyboard device umass # Disks/Mass storage - Requires scbus and da and maybe this will help already. I will let you know and update the PR later the day. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
Re: USB devices sometimes not seen at boot time
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: at usbus1 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub1: on usbus1 uhub0: 13 ports with 13 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen0.2: at usbus0 ugen0.3: at usbus0 ugen0.4: at usbus0 and this is from a bad one: # egrep 'uhub|ugen' dmesg-20170628-202351-bad.txt ugen1.1: at usbus1 ugen0.1: <0x8086 XHCI root HUB> at usbus0 uhub0: 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: at usbus1 uhub2 on uhub0 uhub2: 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"
USB devices sometimes not seen at boot time
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: at usbus1 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub1: on usbus1 uhub0: 13 ports with 13 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen0.2: at usbus0 ugen0.3: at usbus0 ugen0.4: at usbus0 and this is from a bad one: # egrep 'uhub|ugen' dmesg-20170628-202351-bad.txt ugen1.1: at usbus1 ugen0.1: <0x8086 XHCI root HUB> at usbus0 uhub0: 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: at usbus1 uhub2 on uhub0 uhub2: 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? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
