Date: Fri, 30 Jun 2017 08:34:21 +0200 From: Matthias Apitz <guru@unixarea.de> To: Hans Petter Selasky <hps@selasky.org> Cc: freebsd-usb@freebsd.org Subject: Re: USB devices sometimes not seen at boot time Message-ID: <20170630063421.GB10425@c720-r314251> In-Reply-To: <11fac898-a4bc-8337-2d84-8777d136c7e0@selasky.org> References: <20170629194658.GA2488@c720-r314251> <11fac898-a4bc-8337-2d84-8777d136c7e0@selasky.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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: <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. Hi, Thanks for the hint. I disabled the three entries for uhci, ohci and ehci: # USB support options USB_DEBUG # enable debug msgs # device uhci # UHCI PCI->USB interface # device ohci # OHCI PCI->USB interface # device ehci # 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, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAllV8OoACgkQR8z35Hb+ nRE0+Q//XmsMYL4u1z3SY4QairQ1KaObgEhA5sRqS68PkLQJ1gj24cyKdHXzEJaC BDSZfQoTnq0EKaPRDvtYiPuTN8apYGYwfDhjz/S24H+mwIK0U+YuL7mousdzSgOQ GQhePspJWC0PIVzTQt+VxBgeGoS//iWa5AKUVAGBHB9DtbZtNLyxK3yhElZI7ea/ 6RRGICewfxyA3VU8F1d4raU+nVKNcmtwK9gc529IPHT7/u7GdHU006rkDbXANp1c TO/LoZF2Xd8jZ6EVWi6vcnhUCf8WqFeKjU2zT9OmW9hizgjrFGCxChOwahM5pnuX YjNdD0tAn+rY6oDTq1wjm2AbG8Lb77gXrcwriozqEHGw60oY77iiGfAb9y/Vqyuh H3A3sCuepT87ee/IyiY68uOnT9uAkzYxugqk1F4izb0E8HK0sKlpkhpsQY+65o/Z 4XDPfgGtll59wWKAksNc2dX6cb8LMn9KhnmQzcGSEB4SwGcofoS0e1HGbqiC2TDQ Tb5tW17HOR/rfvSuIwZX3PwlvhGNV8w5jhR3QHmwMMF48N7AvUK5X+TRA0PU2hYi jez4Mw+s2YRAjo2OKT05m9MBONcyZMlYxbyC/FdXAPkH3l9aEdaUZElHkT+Kj/TB egfSAbvWRbP1cf81UCzm0yV7edFklunCITFuigLWHIxWMhD2Tns= =raW4 -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170630063421.GB10425>