Date: Wed, 06 Aug 2014 08:38:21 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Dan Mahoney <dmahoney@isc.org> Cc: freebsd-usb@freebsd.org, Peter Losher <plosher@isc.org> Subject: Re: Setting USB probe priority... Message-ID: <53E1CD5D.5010601@selasky.org> In-Reply-To: <alpine.BSF.2.00.1408060627370.32932@bikeshed.isc.org> References: <336D77E7-2845-4F62-9627-75D442CCAB14@isc.org> <53E1C928.8040409@selasky.org> <alpine.BSF.2.00.1408060627370.32932@bikeshed.isc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/06/14 08:34, Dan Mahoney wrote: > > > On Wed, 6 Aug 2014, Hans Petter Selasky wrote: > >> On 08/06/14 01:50, Peter Losher wrote: >>> (please include my and Dan's email in any responses as we normally don't >>> lurk on the USB mailing list) >>> >>> So @work we use serial->USB TTY MUX's to handle our serial console needs, >>> and at some sites we have a need that is greater than a single 16 port >>> device (the max you can get). The problem is that with two of these 16 port >>> USB devices is that sometimes during a reboot that the "second" device gets >>> probed first and so the first 16 and second 16 /dev/ttyU* blocks swap >>> around... which of course plays havoc with any symlinks we have to the >>> devices in rtty or conserver. :( >>> >>> Is there any way to tell the USB code to always select a certain device >>> first? I assume this has been a issue with USB storage devices so this >>> shouldn't be a new issue. And I tried searching for a answer on the web to >>> no avail. >>> >>> Ideas? >> >> Hi, >> >> USB enumerates in sequential order, but sometimes devices might not be ready >> to enumerate, and then a port is skipped. >> >> Does the device have a serial number? >> >> usbconfig -d X.Y dump_device_desc |grep iSerial >> >> If yes, this can be filtered by a devd rule, when the device attaches, and >> then you can switch the serial number to create any symbolic links. > > Curiously, it looks like one of our two usb-to-serial devices (both are > 16-port devices), presents as 16 separate USB devices, and the other > presents as clusters of four: > > iSerialNumber = 0x0003 <FTWVV6Z7> > iSerialNumber = 0x0003 <FTWVV70Y> > iSerialNumber = 0x0003 <FTWVV72I> > iSerialNumber = 0x0003 <FTWVV74C> > iSerialNumber = 0x0000 <no string> > iSerialNumber = 0x0003 <ST160898> > iSerialNumber = 0x0003 <ST160897> > iSerialNumber = 0x0000 <no string> > iSerialNumber = 0x0003 <ST160900> > iSerialNumber = 0x0003 <ST160899> > iSerialNumber = 0x0003 <ST160902> > iSerialNumber = 0x0003 <ST160901> > iSerialNumber = 0x0003 <ST160904> > iSerialNumber = 0x0003 <ST160903> > iSerialNumber = 0x0003 <ST160906> > iSerialNumber = 0x0000 <no string> > iSerialNumber = 0x0003 <ST160905> > iSerialNumber = 0x0003 <ST160908> > iSerialNumber = 0x0003 <ST160907> > iSerialNumber = 0x0003 <ST160910> > iSerialNumber = 0x0003 <ST160909> > iSerialNumber = 0x0003 <ST160912> > iSerialNumber = 0x0003 <ST160911> > > However, if I understand you correctly, not-ready issues aside, what we > really need to do is to ensure that our devices are simply plugged into > USB ports that are probed in the correct order, and assuming they're all > ready to probe, this shouldn't be a problem. > > What I think happened here was that one of these devices was added to > an earlier-sequenced port after bootup. > > Of course, from the back of a server, it's totally non-obvious what the > sequence is. Is there an easy way to tell where in the probe sequence a > given port will be? > > -Dan > Hi, Ports are probed 1,2,3,4, if they are labeled as such. When adding new equipment, you can force a re-enumeration of the root HUB, where the devices are attached, and then the order shall be the same as at reboot: usbconfig -d X.1 set_config 255 usbconfig -d X.1 set_config 0 If the devices are attached to different USB controllers there is no guarantee about the probe order. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53E1CD5D.5010601>