Date: Wed, 6 Aug 2014 06:34:02 +0000 (UTC) From: Dan Mahoney <dmahoney@isc.org> To: Hans Petter Selasky <hps@selasky.org> Cc: freebsd-usb@freebsd.org, Peter Losher <plosher@isc.org> Subject: Re: Setting USB probe priority... Message-ID: <alpine.BSF.2.00.1408060627370.32932@bikeshed.isc.org> In-Reply-To: <53E1C928.8040409@selasky.org> References: <336D77E7-2845-4F62-9627-75D442CCAB14@isc.org> <53E1C928.8040409@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1408060627370.32932>