kernel 2.6.9-34.EL The Palm Pilots with USB create 2 ttyUSB devices when the "hotsync" button is pushed. In some cases (when the hotsync has timed out, or been cancelled), there are 4 ttyUSB devices showing up: visor ttyUSB0: Handspring Visor / Palm OS converter now disconnected from ttyUSB0 visor ttyUSB1: Handspring Visor / Palm OS converter now disconnected from ttyUSB1 usb 4-1: new full speed USB device using address 5 visor 4-1:1.0: Handspring Visor / Palm OS converter detected usb 4-1: Handspring Visor / Palm OS converter now attached to ttyUSB0 usb 4-1: Handspring Visor / Palm OS converter now attached to ttyUSB1 usb 4-1: USB disconnect, address 5 visor 4-1:1.0: device disconnected usb 4-1: new full speed USB device using address 6 visor 4-1:1.0: Handspring Visor / Palm OS converter detected usb 4-1: Handspring Visor / Palm OS converter now attached to ttyUSB2 usb 4-1: Handspring Visor / Palm OS converter now attached to ttyUSB3 ttyUSB0 and ttyUSB1 point to nowhere.
I know, this is bothering everyone, on all versions of 2.6 kernel up to 2.6.20, and is going to continue for the foreseeable future. If a device node is open, we do not dispose of it until the last holder of it closes. So, if the peripheral disconnects and reconnects, the reconnect process can run before the user program exited and then a new node (or a set of two, in this case) is allocated. The situation is made worse by many Pilot-type PDAs disconnecting at the end of a sync operation. Talk about racing. Personally I think that we ought to be able to remove device nodes upon disconnect, no matter who keeps them open. New opens are not allowed, so why keep them around. But this requires some extensive rework in tty layer. So, if you have /dev/pilot pointing to ttyUSB1, it's going to become ineffective until you make sure pilot-link died, and then reconnect. The situation is so notorious that Fedora deals with it by making a rule in udev: KERNEL=="ttyUSB*", ATTRS{product}=="Palm Handheld*", SYMLINK+="pilot", GROUP="uucp", MODE="0660" KERNEL=="ttyUSB*", ATTRS{product}=="palmOne Handheld*", SYMLINK+="pilot", GROUP="uucp", MODE="0660" KERNEL=="ttyUSB*", ATTRS{product}=="Handspring Visor*", SYMLINK+="pilot", GROUP="uucp", MODE="0660" Then your /dev/pilot is maintained by udev and always point to correct node. Maybe we should ask Harald to retrofit this into RHEL 4?
This was my work desktop, which now runs FC6. Unless somebody still using RHEL4 and Palm PDAs reports the same problem, I wouldn't bother fixing this...
So, does the udev ruleset keep your /dev/pilot pointing where it should on FC6?
/dev/pilot still points to the wrong place, as this requires knowing which of the 2 created tty devices is the right one to access this particular device (it changes from model to model). However, the device nodes are getting removed and added properly with the current rawhide. Closing now.