On Thu, Jun 20, 2002 at 08:57:02PM +0100, Nick Craig-Wood wrote: > On Thu, Jun 20, 2002 at 12:27:32PM -0700, Greg KH wrote: > > On Thu, Jun 20, 2002 at 01:41:25PM +0100, Nick Craig-Wood wrote: > > > So now the devices are numbered in a completely illogical fashion. It > > > *seems* to be consistent the numbering scheme from boot to boot but if > > > you move one thing about it all changes. It different on different > > > computers too. > > > > But why do you care about device numbers? Are you trying to talk to the > > raw USB devices instead of their /dev/ttyUSBx number? > > No. I've just got hold of the device numbers as a convenient way of > demonstrating the problem since the /dev/ttyUSBx numbers are assigned > in the same order as the device numbers.
Ok, that makes sense. > > And in testing it seems that different devices at different points in > > the USB tree (like behind hubs) when resetting themselves enumerate > > before other devices. Just like you've noted above. There really is > > nothing we can do about the enumerating issues. > > It just seems annoying that the first enumeration (without firmware) > is exactly how we'd like it, but the second (with firmware) is so > random. I agree. > > > Why does the keyspan driver get a new device number? Surely it would > > > be better to keep the old one which is a) numbered properly and b) > > > doesn't waste a device number > > I'd love to know the answer to this if you've got the time to explain > it! The keyspan devices need firmware to be downloaded to them to work properly. So they first show up as a "empty" device, the driver takes over and downloads the proper firmware to them. Then the device disconnects itself and resets itself, causing the new firmware to run. It then reconnects to the USB bus as the "proper" device, and the driver takes over again. Did that help? > > > (yes we did try connecting > 64 keyspans to one PC ;-) > > > > Nice, did >64 actually work? I've never tested the usb-serial core code > > with that many different devices (I don't have that many.) > > We managed to make 112 serial ports active IIRC. That seemed to be > the limit - no more devices were recognised above that. Powering that > much USB equipment needed an external power supply though and we may > have been running into power limits! I also managed to generate an > Oops while doing these experiments which I have a picture of - I can > decode it if you are interested. I would be, thanks. > > > Can this race like behaviour be fixed? > > > > What exactly do you want to see happen? > > > > I think your problem is that the /dev/ttyUSBx numbers are not assigned > > in a repeatable fashion, correct? > > Yes. Each of the 24 serial ports is connected to something in > particular (bits of equipment that need monitoring) so we need to know > that speaking down /dev/ttyUSBx comes out of a socket with x written > on it. Ok, that's a pretty common requirement. The original io_edgeport driver used to have something that would bind devices to minors, based on the serial number in the device. I don't think the keyspan devices have unique serial numbers. Either way, that code didn't survive when the io_edgeport driver got merged into the kernel, but could provide a base for you if you want to try hacking up the driver a bunch. > > If this is your question, then sorry, but no, 2.4 can not solve > > this issue right now. > > :-( I suppose I can parse the dmesg output and re-arrange the > /dev/ttyUSB device nodes... That's no fun :( > Well sort of! Can you suggest a sensible way of working out which > ttyUSB is attached to which USB bus position (eg bus1/2/4/1) other > than parsing the kernel logs? Hm, can you take a look at the latest 2.5 kernel and see if the information in the /proc/tty/driver/usbserial file could help you out? The USB physical path is in the file for every device, showing where in the USB tree it lives. If that's helpful, I could make a patch for you, adding it to the 2.4 tree. Actually I was going to backport that chunk of code once 2.4.19-final comes out. Let me know if that helps, greg k-h ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
