Bug 203932

Summary:	4 ttyUSB devices instead of 2
Product:	Red Hat Enterprise Linux 4	Reporter:	Bastien Nocera <bnocera>
Component:	kernel	Assignee:	Red Hat Kernel Manager <kernel-mgr>
Status:	CLOSED RAWHIDE	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	jbaron, prarit, zaitcev
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-09-25 14:27:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bastien Nocera 2006-08-24 16:15:52 UTC

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 23:54:03 UTC

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-20 01:24:24 UTC

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-20 01:43:36 UTC

So, does the udev ruleset keep your /dev/pilot pointing where it should on FC6?

Comment 5 Bastien Nocera 2007-09-25 14:27:08 UTC

/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.