Bug 203932 - 4 ttyUSB devices instead of 2
4 ttyUSB devices instead of 2
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Kernel Manager
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-24 12:15 EDT by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-25 10:27:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bastien Nocera 2006-08-24 12:15:52 EDT
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.
Comment 1 Pete Zaitcev 2007-02-19 18:54:03 EST
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?
Comment 2 Bastien Nocera 2007-02-19 20:24:24 EST
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...
Comment 3 Pete Zaitcev 2007-02-19 20:43:36 EST
So, does the udev ruleset keep your /dev/pilot pointing where it should on FC6?
Comment 5 Bastien Nocera 2007-09-25 10:27:08 EDT
/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.

Note You need to log in before you can comment on or make changes to this bug.