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. > 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. > > Also perhaps related on initial enumeration on some hardware one of > > the keyspan units never gets its firmware. > > That's not good. Any debug log messages? I'll dig some out from the machine in question in a little while. > > However using only one hub in the system (with <= 4 keyspans) > > everything is fine. > > Ah, because the timing is all the same (they all go through the same > hub, so are talked to in the same order). Make sense. > > 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! > > (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. > > 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. > 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... > There are plans for the ability to assign specific minor numbers to > specific usb serial devices to be added to 2.5, or at least > reporting to userspace, what physical devices have what minor > numbers (like David stated.) But that work is still ongoing, and > there isn't anything usable yet, sorry. I don't care particularly about which device has which number, just that they stay in the same order. The order that they are first emumerated in would be perfect! > Does this help? 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? Thanks Nick -- Nick Craig-Wood [EMAIL PROTECTED] ------------------------------------------------------- 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
