Bug 158809 - Udev slow to create dev entries for ttyUSB
Udev slow to create dev entries for ttyUSB
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
:
: 161058 175859 238418 (view as bug list)
Depends On: 411321
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-25 19:36 EDT by Gavin Graham
Modified: 2013-05-23 11:02 EDT (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:10:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
udev rules that pilot-link suggests (2.52 KB, text/plain)
2007-05-02 13:13 EDT, James Ralston
no flags Details
udev rules (4.54 KB, application/octet-stream)
2007-06-13 18:09 EDT, James Ralston
no flags Details
console.perms file for /etc/udev/rules.d/60-libpisock.rules (186 bytes, application/octet-stream)
2007-06-13 18:10 EDT, James Ralston
no flags Details
blacklist the visor driver (16 bytes, application/octet-stream)
2007-06-13 18:10 EDT, James Ralston
no flags Details
udev rules (4.54 KB, text/plain)
2007-06-13 18:12 EDT, James Ralston
no flags Details
console.perms file for /etc/udev/rules.d/60-libpisock.rules (186 bytes, text/plain)
2007-06-13 18:13 EDT, James Ralston
no flags Details
blacklist the visor driver (16 bytes, text/plain)
2007-06-13 18:14 EDT, James Ralston
no flags Details

  None (edit)
Description Gavin Graham 2005-05-25 19:36:10 EDT
Updated FC4-t3 udev to 0.58-1 and now it takes 30 seconds (sometimes longer) to
create the /dev/ttyUSB0 & /dev/ttyUSB1 entries when hotsyncing a palm device.
By the time the entries have been created, the Palm device has stopped polling.
As a result, the pilot-link suite never gets a connection to the Palm device.

This has only started since updating udev to 0.58-1
Comment 1 Dave Jones 2005-08-04 02:18:47 EDT
*** Bug 161058 has been marked as a duplicate of this bug. ***
Comment 2 Paul Bolle 2005-08-04 05:13:50 EDT
Wouldn't it be better to "upgrade" this bug to FC4, so it will show up directly
when querying on FC4, just as bug 161058 does (but only when searching on closed
bugs)?

(This is of course a more general issue with testing bugs: why aren't (unclosed)
testing bugs upgraded (or cloned, etc.) to the "final" release when that final
release is available? This would mean that test releases reach their end-of-life
- their bug reports at least - when the final release is available ...)
Comment 3 Gavin Graham 2005-08-05 02:48:24 EDT
Upgraded to Fedora Core 4 as this problem is persistant.
Comment 4 Keith McDuffee 2005-09-08 15:54:02 EDT
From duplicate bug 161058, a temporary solution for anyone still sitting
frustrated at not having pilot-xfer working with your Palm device, try the
following:

As root:

mknod /tmp/pilot c 188 1
chown your_user_name /tmp/pilot

Then use the flag '-p /tmp/pilot' for pilot-xfer. Working great for me so far.
Comment 5 Gilboa Davara 2005-09-09 05:02:17 EDT
Keith,

Did you get gpilotd to work with it?
I'm using the latest pilot-* and gnome-pilot-* from -testing; pilot-*
(pilot-xfer, etc) work just fine.
Under gpilotd, the palm device trys to sync and immediately quits.
Comment 6 Gilboa Davara 2005-09-09 05:09:21 EDT
Come to think about it.
This belongs to another bug report (gnome-pilot doesn't play well with shipped
pilot-link). Please ignore my last post.
Comment 7 Craig White 2005-10-05 19:02:32 EDT
FC-3 (not FC-4)
# uname -rm
2.6.12-1.1376_FC3 i686

My solution (temporary until udev works per above)

as root...

mknod /tmp/pilot c 188 1
chown craig /tmp/pilot

plug in treo and press hotsync button

as craig (cli)

pilot-xfer -L -p /tmp/pilot

Works - got file list from Treo

so to make gpilotd work I had to add...

 <!-- Handspring Treo 650 -->
 <device vendor_id="0830" product_id="0061" />

to /usr/share/gnome-pilot/devices.xml
Comment 8 Jens Ziemann 2005-10-12 13:05:38 EDT
tried today on FC4 with Kernel 2.6.13-1.1526_FC4:

once I plug the USB Cable of my Tungsten T5 into the PC (Dell Latitude D800) it
takes max 4 seconds until my T5 is in Nirvana and needs a hard-reset :-(

this is reproducable every time.
Comment 9 Patrick C. F. Ernzer 2005-10-15 16:54:49 EDT
Jens,

just tried under FC4 with kernel 2.6.13-1.1526_FC4, a device node of ~/dev/pilot
(as per comment #7), jpilot-0.99.8-0.pre10.fc4.1 and
pilot-link-0.12.0-0.pre4.0.fc4.2 I can sync to jpilot just fine and get no hang
on my T5 (Palm OS 5.4.8)

PC is a desktop machine (A7V600-X mainboard FWIW)
Comment 10 Gavin Graham 2005-10-23 00:10:44 EDT
Updating to a rawhide udev solved all the problems without having to kludge dev
entries.
Comment 11 Adam Pribyl 2005-12-17 13:35:38 EST
I came to this bug as I have similar issue but with HP Jornada 720. There is
situation bit worse as the Jornada timeout is only 3-4s and udev/hotplug takes
6-7 seconds to start synce-start-serial that is defined in
/etc/udev/scripts/synce.dev (synce package is from fedora extras).

Dec 17 13:03:01 fb kernel: ohci_hcd 0000:00:02.0: wakeup
Dec 17 13:03:02 fb kernel: usb 2-7: new full speed USB device using ohci_hcd and
address 11
Dec 17 13:03:02 fb kernel: ipaq 2-7:1.0: PocketPC PDA converter detected
Dec 17 13:03:02 fb kernel: usb 2-7: PocketPC PDA converter now attached to ttyUSB0
Dec 17 13:03:06 fb kernel: usb 2-7: USB disconnect, address 11
Dec 17 13:03:06 fb kernel: PocketPC PDA ttyUSB0: PocketPC PDA converter now
disconnected from ttyUSB0
Dec 17 13:03:06 fb kernel: ipaq 2-7:1.0: device disconnected

When I start in the mean time synce-serial-start manualy then device connects OK.
Comment 12 Suzanne Hillman 2005-12-22 20:42:05 EST
Yesterday, I was generally able to get the "mknod /tmp/pilot c 188 1
chown your_user_name /tmp/pilot" method to work, from comment 4, but today it's
just not cooperating (this may be because I updated; not sure if udev was one of
the packages updated or not).

I'm not sure if this is the same problem or not, so I add my info to the pile.

It looks to be starting to create the /dev/ttyUSB{0,1} devices, but somehow not
finishing them. By this, I mean... before I hit the sync button, there is
nothing there:

"# ls -l /dev/ttyUSB*
ls: /dev/ttyUSB*: No such file or directory"

When I hit the sync button, the following shows up in /var/log/messages:

"Dec 22 20:30:44 phoenix kernel: usb 1-2: new full speed USB device using
ohci_hcd and address 13
Dec 22 20:30:44 phoenix kernel: visor 1-2:1.0: Handspring Visor / Palm OS
converter detected
Dec 22 20:30:44 phoenix kernel: usb 1-2: Handspring Visor / Palm OS converter
now attached to ttyUSB0
Dec 22 20:30:44 phoenix kernel: usb 1-2: Handspring Visor / Palm OS converter
now attached to ttyUSB1"

And approximately 5 seconds later, I see: 

"# ls -l /dev/ttyUSB*
crw-rw----  1 root uucp 188, 0 Dec 22 20:30 /dev/ttyUSB0
crw-rw----  1 root uucp 188, 1 Dec 22 20:30 /dev/ttyUSB1"

But the text of the device names are yellow on a black background, which I seem
to recall happens when a device is created on the filesystem, but nothing
actually exists. (the /dev/pilot link is also not created)

udev-058-1.0.FC4.1 - which is I believe the most recent version available.

I do also note that the visor module does appear to be loaded:

# lsmod | grep visor
visor                  19149  0
usbserial              30377  1 visor
Comment 13 Kevin R. Page 2006-01-22 13:04:14 EST
To confirm, this is still an issue with kernel-2.6.14-1.1656_FC4,
udev-058-1.0.FC4.1, and a Treo 650.

As per the initial report, pressing the hotsync button is required to activate
the USB connection, but by the time udev has created the device nodes the Treo
has given up polling for the higher level sync software (i.e. pilot-xfer).

However, it would appear that only some Palm devices time out before udev
creates the device node: a Palm Tungsten T syncs fine (once the device node is
finally created), but on the same machine a Treo 650 times out.

N.B. There is no immediate error on the Treo that it has timed out - it appears
to be waiting for hotsync, while pilot-xfer waits forever at:
Listening for incoming connection on /dev/pilot

The "mknod /tmp/pilot c 188 1" kludge works as expected.
Comment 14 Brian Johnson 2006-01-30 10:06:52 EST
Where is a good place to insert those 'kludge' commands to make it happen every
boot (in case /tmp gets emptied)?
Comment 15 Gilboa Davara 2006-01-30 18:32:47 EST
Why not create /etc/dev (this is what I do) though every other place (/usr/dev,
etc) should work just as well.
Comment 16 Adam Pribyl 2006-01-31 04:47:51 EST
The problem with devices that you create either by mknod or by copiing them to
/etc/udev/devices or anything else is, that when this device is managed anyhow
by udev, then it is deleted when you remove device. At least this is how it
works with ttyUSBx. You can create it manualy, but it will be deleted on device
removal, next time it will not be created in time again.
Comment 17 Gilboa Davara 2006-01-31 08:03:01 EST
Just put the mknoded devices outside of udev reach (I usually put them in /etc/dev).
udev will be unaware of /etc/dev (or /usr/dev), and there-fore will not touch
them when the device disconnects.
Comment 18 Gavin Graham 2006-02-03 17:23:23 EST
That is a "band-aid" fix and not the real solution. UDEV should be able to
manage this in a timely manner by itself.
Comment 19 Gilboa Davara 2006-02-04 04:59:04 EST
... Should :(
Comment 20 Serge 2006-02-14 02:34:06 EST
Seems to be fixed with udev-071-0.FC4.2 no ? 
Comment 21 Adam Pribyl 2006-02-14 09:52:46 EST
The situation does not change for me. It is true that ttyUSB0 is maybe created
fast enought, but the start of synce.dev (the script) is somewhat slow...
Comment 22 Gilboa Davara 2006-03-03 04:39:58 EST
Same here. pilot-xxx and gnome-pilot still timeout.
Back to static ttyUSB0/1 for me.

Once I'll have some free time I'll give FC5T3 a test run.
Comment 23 Need Real Name 2006-03-09 16:25:56 EST
*** Bug 175859 has been marked as a duplicate of this bug. ***
Comment 24 Christian Iseli 2007-01-19 20:02:29 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 25 Gilboa Davara 2007-01-20 02:22:52 EST
Still happening on FC6.
Please change target to FC6.

- Gilboa
Comment 26 Gilboa Davara 2007-01-20 02:40:19 EST
Information provided above.
Comment 27 James Ralston 2007-01-21 14:25:14 EST
For a while now, it's been the case that udev creates the /dev/ttyUSB{0,1} nodes
very quickly; usually in about a second or so.

However, hotsync'ing still only works sporadically.  This seems to be true no
matter how quickly I press the "sync" button in jpilot after pressing the
hotsync button on my Palm.  Sometimes it syncs the first time.  Usually, I have
to try a few times before it'll sync.  Sometimes I have to try almost a dozen times.

It's irritating, but not overly so.
Comment 28 Harald Hoyer 2007-01-22 09:25:54 EST
how about fixing the application?
Comment 29 James Ralston 2007-01-23 19:07:27 EST
Because it's not the application's fault.  The problem is that occasionally, the
select() call on /dev/pilot never returns.  (This is unrelated to how long it
takes udev to create the device nodes.)
Comment 30 Harald Hoyer 2007-01-24 04:50:07 EST
That is because the ttyUSB device nodes are recreated in the kernel and can
change numbers (some pilots disconnect and reconnect to the USB bus on a hotsync
button press). So the app should, look in HAL for the device nodes, which the
pilot device has and try both of them, and after the user pressed the hotsync
button scan for HAL changes and reopen those devices.
Comment 31 James Ralston 2007-01-24 12:16:15 EST
pilot-link isn't HAL-aware, and IMHO, shouldn't need to be in order to complete
a HotSync operation.  Simply reading/writing from/to a tty should be sufficient.

Regardless, however, your comment gave me the needed clue to figure out the
problem: the select() call occasionally hangs because udev occasionally symlinks
/dev/pilot to /dev/ttyUSB0 instead of /dev/ttyUSB1:

# CORRECT RUN: I press the HotSync button on my Palm...

$ ls -lsa /dev/pilot /dev/ttyUSB*
0 lrwxrwxrwx 1 root    root      7 Jan 24 12:08 /dev/pilot -> ttyUSB1
0 crw------- 1 example uucp 188, 0 Jan 24 12:08 /dev/ttyUSB0
0 crw------- 1 example uucp 188, 1 Jan 24 12:08 /dev/ttyUSB1

$ pilot-xfer -p /dev/pilot -l 1>/dev/null 
   Listening to port: /dev/pilot
   Please press the HotSync button now... Connected

# INCORRECT RUN: I press the HotSync button on my Palm...

$ ls -lsa /dev/pilot /dev/ttyUSB*
0 lrwxrwxrwx 1 root    root      7 Jan 24 11:57 /dev/pilot -> ttyUSB0
0 crw------- 1 example uucp 188, 0 Jan 24 11:57 /dev/ttyUSB0
0 crw-rw---- 1 root    uucp 188, 1 Jan 24 11:57 /dev/ttyUSB1

$ pilot-xfer -p /dev/pilot -l 1>/dev/null 
   Listening to port: /dev/pilot
   Please press the HotSync button now... ^C

$ pilot-xfer -p /dev/ttyUSB1 -l 1>/dev/null 
   Listening to port: /dev/ttyUSB1
   Please press the HotSync button now... Connected

I don't know why udev is doing this, but I don't see how it can't be wrong;
/dev/pilot should always be symlinked to /dev/ttyUSB1, because /dev/ttyUSB1 is
always the correct device to open.  (Or at least I've never seen a single
instance where opening ttyUSB0 worked.)
Comment 32 Harald Hoyer 2007-01-24 12:36:48 EST
what if another USB device acquired ttyUSB0-ttyUSB4 before you plugin the pilot?
Comment 33 Eric Hopper 2007-01-24 13:14:16 EST
(In reply to comment #31)
> pilot-link isn't HAL-aware, and IMHO, shouldn't need to be in order to complete
> a HotSync operation.  Simply reading/writing from/to a tty should be sufficient.

I thought about this a bit, and it can't be strictly true.  Something has to
know which /dev/ttyUSB device is a Palm Pilot and which isn't.  I don't think
it's possible for udev to have all the needed information to know what to link
/dev/pilot to in all cases.  Especially if you're using a USB RS-232 adapter to
connect to an older RS-232 based Palm Pilot.

Maybe the best answer is to have it pick appropriately whenever it can tell by
the USB id alone and otherwise not link /dev/pilot to anything.  If /dev/pilot
isn't linked, pilot-xfer could query all the /dev/ttyUSB ports looking for a
Palm Pilot or something.

Anyway, just a random idea after seeing this exchange.
Comment 34 James Ralston 2007-04-13 13:53:01 EDT
Ok.

After spending some time digging through pilot-link, and spending a lot of time
pondering, I now think that Harald's comment 28 was correct: the best thing to
do is to fix the application.

The fundamental issue here is that the kernel's visor driver is essentially a
backwards compatibility layer for applications that don't understand the USB
subsystem, and just want to use a serial port to HotSync.  That is,
fundamentally, what the visor driver does: it provides device files that look
like serial ports in order to talk to a USB device.

All of the problems that people have experienced trying to HotSync on Linux
(including this bug and others) boil down to the fact that compatibility layers
are easy to perturb.

Fortunately, the pilot-link developers agree.  Version 0.12.0 of pilot-link,
released on 2006-09-04, includes native USB support.  Meaning, that instead of this:

$ pilot-xfer -p /dev/pilot -l

You can simply do this:

$ pilot-xfer -p usb: -l

...and pilot-xfer will scan USB devices looking for Palm-compatible devices.  If
it doesn't find any, it will wait until it receives one.

There are some additional udev rules that are needed; these are described in the
README.libusb file in the pilot-link package.  You also have to blacklist the
visor driver (otherwise the kernel will load it, and it will grab the device
instead), but it's doable.  In fact, I've been using this configuration for months.

The only problem I haven't been able to solve is that the character devices that
are created under /dev/bus/usb are always owned by root, which doesn't work,
because pilot-link needs to be able to both read from and write to them.  I've
been hacking around this by running this command (as root) after I press the
HotSync button on my pilot:

$ find /dev/bus/usb -mmin -1 -type c | xargs -e -r -t chown username:username

Then pilot-link can successfully HotSync.  It just works.

So, I'm not sure what package/service is responsible for the ownerships in
/dev/bus/usb, but that definitely needs to be corrected.

I'm going to file another bug against pilot-link, as udev, pilot-link, and
potentially other packages will all need to be updated in lockstep to make this
work.
Comment 35 James Ralston 2007-04-13 14:08:54 EDT
I filed bug 236413 against pilot-link.
Comment 36 Adam Pribyl 2007-04-14 16:49:31 EDT
I think the ownership should be managed by udev...
Comment 37 James Ralston 2007-04-16 11:17:56 EDT
Well, from tracing through udev in debug mode, it's clear that udev expects the
pam_console_apply helper to set the permissions on the device node:

Apr 16 10:49:38 example udevd-event[22445]: run_program:
'/sbin/pam_console_apply /dev/bus/usb/003/005 '

The tricky part is that the device node created for the Palm device won't look
any "different" than any other USB device nodes, and a generic rule that says
"anything under /dev/bus/usb should be owned by the console user" is probably
too broad.

Harald, do you see any easy way to do this?
Comment 38 Harald Hoyer 2007-04-17 03:44:34 EDT
- general write permissions for console users (problem with USB disks)
- suid pilot-link only for console users (problem with buffer overflow attacks)
- additional helper app called for known product/vendor
Comment 39 James Ralston 2007-05-02 13:13:22 EDT
Created attachment 153968 [details]
udev rules that pilot-link suggests

Ok, it looks like there isn't already an easy hook to do this.	General write
permissions for console users and suid pilot-link only for console users are
both no-ops.

It looks like an additional helper app is the best solution.  In fact,
pilot-link might already be trying to do this, because it suggests putting a
bunch of rules (attached) in /etc/udev/rules.d.

The suggested rules identify all Palm and compatible devices.  The
GROUP="dialout" line makes me suspect the point of the rules is to get write
permission for the console user, but I'm not sure.

How about this: have udev call /sbin/pam_console_apply for the specific Palm
devices; use the -c option to specify an alternate console.perms file that
dictates that the console user should own all device files under /dev/bus/usb. 
(This would be wrong in the general case, but since these rules will only be
used in this specific case that /sbin/pam_console_apply is being applied to a
Palm device, this should be ok.)

I think it would be cleaner if there were some way to just tell
pam_console_apply, "look, I know you don't have this device file in your
configuration, but make it owned by the console user with group blah and mode
blah."	But pam_console_apply doesn't seem to have that ability.
Comment 40 Harald Hoyer 2007-05-03 04:46:19 EDT
then pilot-link should ship these rules and helper apps.. pam_console_apply is
called for _every_ device node. Just put in some config files.
Comment 41 James Ralston 2007-06-13 18:07:54 EDT
Ok.  I'm going to attach three files.  They are:

/etc/udev/rules.d/60-libpisock.rules

This file contains udev rules to match pilot devices.  In order to get the
console permissions correct, the rules use /sbin/pam_console_apply with a custom
console.perms file.  (Someone who speaks udev better than I do could probably
remove some of the redundancy in this file.)

/etc/security/console.perms.pilot-link

The console.perms files that /etc/udev/rules.d/60-libpisock.rules uses.

/etc/modprobe.d/blacklist-visor 

This file blacklists the visor driver, so that the kernel won't load it.  (I've
yet to find a way to make the blacklist take effect other than by rebooting.)

If you install all 3 of these files, reboot, and ensure that pilot-link is
compiled with native USB support (which is *NOT* the case as of this writing;
see bug 236413), then configure jpilot to use "usb:" as the device file to use,
everything works.  I'm using this configuration right now.
Comment 42 James Ralston 2007-06-13 18:09:04 EDT
Created attachment 156931 [details]
udev rules
Comment 43 James Ralston 2007-06-13 18:10:06 EDT
Created attachment 156932 [details]
console.perms file for /etc/udev/rules.d/60-libpisock.rules
Comment 44 James Ralston 2007-06-13 18:10:52 EDT
Created attachment 156933 [details]
blacklist the visor driver
Comment 45 James Ralston 2007-06-13 18:12:57 EDT
Created attachment 156934 [details]
udev rules

Sigh... so much for "autodetecting" the file type.  Fixing...
Comment 46 James Ralston 2007-06-13 18:13:35 EDT
Created attachment 156935 [details]
console.perms file for /etc/udev/rules.d/60-libpisock.rules
Comment 47 James Ralston 2007-06-13 18:14:37 EDT
Created attachment 156936 [details]
blacklist the visor driver
Comment 48 James Ralston 2007-07-03 17:15:34 EDT
Any chance of getting these changes into Fedora Development anytime soon?  I've
been using it for almost a month, and it Just Works.

Note you will need pilot-link compiled with native USB support as well; see bug
236413.
Comment 49 Ivana Varekova 2007-08-22 09:33:35 EDT
Hello, for now pilot-link package is build with --enable-libusb. The other bug -
which is described from comment #34 is in my opinion hal problem and should be
fixed by hal -> rassign to hal.
Comment 50 Ivana Varekova 2007-08-23 06:25:33 EDT
*** Bug 238418 has been marked as a duplicate of this bug. ***
Comment 51 Ivana Varekova 2007-09-24 09:29:24 EDT
*** Bug 280251 has been marked as a duplicate of this bug. ***
Comment 52 Joe Christy 2007-09-24 10:23:41 EDT
I must respectfully disagree with marking 280251
(https://bugzilla.redhat.com/show_bug.cgi?id=280251) as a duplicate of this bug.

I cannot distinguish my problem from that in 280251, both symptoms and work
around, _BUT_ in my case, udev creates the /dev entries nearly instantaneously.
What appears to be going wrong, is that my Palm Z22 and udev are creating too
many entries in /dev, confusing both pilot-xfer and KpilotDaemon, which I use
for syncing.

In more detail, attaching my Z22 creates /dev/ttyUSB0 and /dev/ttyUSB1, and udev
will (apparently non-deterministically) link one or the other to /dev/pilot,
which the syncing applications will follow if they are started before I tap the
sync button on my Z22. Sadly, when I then tap the sync button, /dev/ttyUSB2 and
/dev/ttyUSB3, and udev will move the link from /dev/pilot to one of the new
ttyUSB?'s, but the syncing apps are still using whichever of the old ttyUSB?'s
the dev/pilot link originally pointed to.

If I then cancel the sync on my Z22, the next tap on its sync button creates two
 more ttyUSB?'s.

The workaround that allows me to sync is to first tap the sync button on my Z22,
then lickedy-split launch either pilot-xfer or Kpilot from the commandline.

As a recent thread on the Fedora list (Getting GPilot and J-Pilot to Play Nice)
seems to confirm, the problem probably could be fixed by appropriate udev rules.
If someone will give me one each of every extant Palm OS based PDA a/o
Smartphone, I would be glad to write the neccessary rules ;).
Comment 53 Brian Morrison 2007-09-24 10:40:23 EDT
The two bugs (this one and https://bugzilla.redhat.com/show_bug.cgi?id=280251)
are actually complaining about subtly different things.

One is a problem with /dev/ttyUSB* and linking the correct node to /dev/pilot,
then using a serial port wrapper for a USB connections using the visor driver,
that is the thrust of bug 280251.

This bug is about the libusb (a much preferred method for syncing) not being
configured correctly so the device is not located.

If this bug is fixed, and the configuration for any Pilot sync app (GPilot,
JPilot etc) is defaulted to an address usb:, then bug 280251 *should* then be
redundant because few people will need to use the old method.

The problem is that if the visor module is blacklisted, then should someone have
a PDA that won't work with libusb for any reason, they will need to comment out
the entry in /etc/modprobe.d/blacklist-palm so that the module can load and
allow the use of /dev/ttyUSB* and /dev/pilot

If anyone disagrees with this, please discuss and explain why :)
Comment 54 James Ralston 2007-09-24 10:49:42 EDT
Brian, I agree with your assessment; the correct resolution for bug 280251 is to
have pilot-tools use libusb instead of the visor kernel module.  That's why bug
280251 is a dupe.

I can't think of a way someone could have a PDA that won't work with libusb (the
device, after all, doesn't know what "stack" is being used on the host PC to
talk to it), but if we encounter that situation, the correct course of action
would be to attack the problem in libusb, not abandon using libusb for the visor
module.

I haven't had a chance to check yet... does syncing in F8test2 work correctly
(using libusb) out of the box?
Comment 55 Alex Lancaster 2007-09-24 10:59:20 EDT
(In reply to comment #54)
> Brian, I agree with your assessment; the correct resolution for bug 280251 is
to have pilot-tools use libusb instead of the visor kernel module.  That's why
bug 280251 is a dupe.
 
> I can't think of a way someone could have a PDA that won't work with libusb 

Unfortunately that's not always the case, libusb doesn't work on all devices,
see David D's (maintainer of pilot-link, he should know!) comment:

http://mail.gnome.org/archives/gnome-pilot-list/2007-September/msg00006.html

> (the device, after all, doesn't know what "stack" is being used on the host PC to
> talk to it), but if we encounter that situation, the correct course of action
> would be to attack the problem in libusb, not abandon using libusb for the
visor module.

True, but it's useful if the correct udev configuration for using the visor
module is present, should it be necessary to drop back to using the visor
module.  So the fix isn't mutually exclusive.
Comment 56 Alex Lancaster 2007-09-24 11:01:33 EDT
Even more pointedly, David Desrosiers says in the same e-mail:

"No distro should be shipping with Palm libusb enabled by default. They're more
than welcome to build their pilot-link/libpisock packages
with libusb support, but enabling that iterface by default (i.e.
disabling visor in the process), is definitely not something they should
be doing. "
Comment 57 Brian Morrison 2007-09-24 12:01:07 EDT
Yes, that's true, I forgot about that. In fact I've not yet succeeded in getting
my Palm TX to work with libusb (it's given me enough trouble with the visor
module method) and I know a fix went into pilot-link 0.12.2 specifically to deal
with a problem with the TX and libusb. I can't yet confirm it works for me but I
will be trying James' suggested fix to see if it does.

Using a network sync is very reliable though, but it means more configuration on
the Palm!
Comment 58 Brian Morrison 2007-09-25 05:49:40 EDT
(In reply to comment #52)

> What appears to be going wrong, is that my Palm Z22 and udev are creating too
> many entries in /dev, confusing both pilot-xfer and KpilotDaemon, which I use
> for syncing.
> 
> In more detail, attaching my Z22 creates /dev/ttyUSB0 and /dev/ttyUSB1, and udev
> will (apparently non-deterministically) link one or the other to /dev/pilot,
> which the syncing applications will follow if they are started before I tap the
> sync button on my Z22. Sadly, when I then tap the sync button, /dev/ttyUSB2 and
> /dev/ttyUSB3, and udev will move the link from /dev/pilot to one of the new
> ttyUSB?'s, but the syncing apps are still using whichever of the old ttyUSB?'s
> the dev/pilot link originally pointed to.

To add to this Joe, for any given Palm device, the correct device node will be
either /dev/ttyUSB0 or 1 and it will be fixed for that device (i.e. any Z22 will
always need that same device node linked to /dev/pilot) and this will also be
the case for where /dev/ttyUSB2 and 3 are created, the correct one will always
be /dev/ttyUSB(n+2) where n is 0 or 1 as described above. As an unsubstantiated
comment, I think that most USB Palms use /dev/ttyUSB1 these days, but the
Tungsten T used /dev/ttyUSB0 for some reason. pilot-link.org may have
information on this for all the various Palms/Handsprings/Clies/Zodiacs etc, but
I don't have a URI.

If udev is linking the wrong /dev/ttyUSB? to /dev/pilot, then that is a bug in
the rule or a udev bug, I don't know which.

I agree that if the sync application grabs /dev/pilot and subsequently udev
moves the /dev/pilot link to point to a different device node, it will fail to
work properly. This is why the current advice is not to click the application
sync button for a couple of seconds after the hardware sync button is pressed on
the Palm, but if udev is slow even this won't help as several different timeouts
interact.
Comment 59 Brian Morrison 2007-09-25 05:57:41 EDT
Actually, there is some information here:

http://www.pilot-link.org/node/111  for Handspring devices
http://www.pilot-link.org/node/112  for miscellaneous devices
http://www.pilot-link.org/node/113  for Palm and palmOne devices
http://www.pilot-link.org/node/114  for Sony devices

I hope that's useful
Comment 60 James Ralston 2007-09-25 12:38:36 EDT
I must respectfully disagree with David Desrosiers in comment 56: if distros
don't at least *attempt* to ship with Palm libusb enabled by default, no one is
going to be testing it, because the steps to configure libusb by default are
beyond what most people are going to take the initiative to do on their own.

We currently in the F8 test cycle.  IMHO, now would be a *very* good time to
enable libusb by default.  If it breaks, then simply revert back to the visor
module for F8 final, but make sure libusb support is compiled into pilot-tools
so that people who don't have problems with libusb have the option to configure
it for themselves.
Comment 61 Kevin R. Page 2007-11-23 12:00:37 EST
Sync to Palm devices using pilot-link in Fedora 8 is still completely broken
(could owner or assignee amend the release tag, please?).

Having trawled through bugzilla and mailing lists, what I see are lots of
arguments about whether it's a problem in the pilot-link package or the udev
package, how broken the visor module is, how libusb would sidestep the problem,
how we can't turn libusb on by default yet, etc. etc.

These arguments seem kind of pointless, since as it stands Fedora 8 doesn't
include a working configuration for EITHER, let alone one enabled in preference
to the other! Back in the day, I remember Fedora/Redhat releases where I
connected a Palm and it Just Worked - this is a pretty poor state of affairs.

Over the last few releases both pilot-link and udev have changed a lot, so there
are bound to have been problems inflicted upon each other. It's been a moving
target, and this has complicated much of the discussion and bug resolution.

Might I suggest the pilot-link package at the very least ships with working
configurations for both visor and libusb in /usr/share/pilot-link, and a README
to explain how a user might put one configuration or the other in place.

Even if the config files are carried in the pilot-link package, we could do with
reassurance from udev maintainers that these files destined for
/etc/udev/rules.d/ and /etc/security/console.perms.d/ are technically correct.
Once we have a consistent and standard set of configs, we can move on to see if
there are timing problems etc. between udev and pilot-link.

This bug seems to have reasonable configs for libusb attached - would someone
udev knowledgeable like to sign them off?

Bug #280251 has suggested configurations for visor, and I've attempted to
summarise my current understanding in bug #280251 comment #11. But again, it
would be useful it a udev maintainer could critique these configs.
Comment 62 Harald Hoyer 2007-11-29 07:38:08 EST
Here is a solution for Fedora 8
http://www.harald-hoyer.de/linux/console_acls_for_palm
Comment 63 Ivana Varekova 2007-11-30 03:46:22 EST
Test version of pilot-link package - pilot-link-0.12.2-9.fc8 which contains
Harald Hoyer solution (thanks for your great help) is build now.
Comment 64 Fedora Update System 2007-12-03 06:46:05 EST
pilot-link-0.12.2-9.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pilot-link'
Comment 65 Leszek Matok 2007-12-05 13:34:21 EST
This fix is probably responsible for hal-acl-tool segfaulting. Please see bug
#411321.
Comment 66 Till Maas 2008-01-05 08:25:43 EST
according to the comments it seems to be still there with Fedora 8, so I guess
this bug is also there with Fedora 7
Comment 67 Lenny G. Arbage 2008-01-23 00:47:18 EST
I am running with pilot-link-0.12.2-17.fc8 and cannot get anything to happen re:
pilot-xfer.  I've tried the visor method as well as the libusb method as
described in #280251, as well as the harold-hoyer direct modification stuff.  No
sync, ever.

I do get a
kernel: usb 3-2: new full speed USB device using uhci_hcd and address 4
kernel: usb 3-2: configuration #1 chosen from 1 choice

and then later a
kernel: usb 3-2: USB disconnect, address 4

when the hotsync fails.

I've tried with gnome-pilot, but all the above is via pilot-xfer.

I have no idea what to try next.  Is there some extra debugging I can turn on?
Comment 68 Kevin R. Page 2008-01-23 04:11:14 EST
Lenny:
- what Palm device are you using?
- what version of the udev package do you have installed?
- does "pilot-xfer -p usb: -l" work as root?
- is this a clean install, or might you have some manual configuration left over
from previous attempts? These may conflict with the new configs. libusb should
work in pilot-link-0.12.2-17.fc8 without any additional config.

That you don't get a mention of the visor module in messages is a good sign that
the newer pilot-link package has disabled visor. Have you seen README.Fedora in
this package?
Comment 69 Lenny G. Arbage 2008-01-23 11:16:38 EST
This is a Sony Clie (SJ20/U)(In reply to comment #68)
> Lenny:
> - what Palm device are you using?

Sony Clie SJ20/U


> - what version of the udev package do you have installed?

udev-116-3.fc8


> - does "pilot-xfer -p usb: -l" work as root?

No, doesn't work as root either.


> - is this a clean install, or might you have some manual configuration left over
> from previous attempts? These may conflict with the new configs. libusb should
> work in pilot-link-0.12.2-17.fc8 without any additional config.

This is an upgrade for fc6, and there certainly might be left over config; I've
tried to be very careful about exorcising non fc8 packages that were left after
the upgrade, and I've checked all the files that I think might be involved
(60-libpisock.rules, /usr/share/PolicyKit/policy/pilot-device-file.policy,
/usr/share/hal/fdi/policy/10osvendor/20-pda-acl-management.fdi, etc) but there
must be something I am missing....  any ideas?

 
> That you don't get a mention of the visor module in messages is a good sign that
> the newer pilot-link package has disabled visor. Have you seen README.Fedora in
> this package?

Yes, visor is blacklisted.  I will go through the 'disable libusb' instructions
in the readme again and see if that gets me anywhere (didn't have luck with this
before).  Thanks for the pointers -- if you think of anything I else I can try
that might shed some light I'd be happy to give it a whirl.
Comment 70 Kevin R. Page 2008-01-23 12:01:22 EST
(In reply to comment #69)
> > - what version of the udev package do you have installed?
> udev-116-3.fc8

There's a udev update available you'll need - however this "only" fixes a
permission problem for non-root problems. Also make sure udev is running -
there's a bug which crashes udev the first time only after install (as mentioned
in bug #280251).

The new PolicyKit configs almost exclusively deal with correctly setting
permissions for the logged in user, so if you can't even list the Palm contents
as root it may be a problem with libusb in pilot-link itself.

What does lsusb say? From a quick browse of the pilot-link source you should get
vendor/product ID 0x054c/0x0066.

Long term you'll be better served getting libusb to work. But if you decide you
need to try using the visor module, check you see visor module output in
/var/log/messages and the creation of ttyUSBx devices when you connect the Palm.
If it's not even getting that far, this should probably be a separate bug
against pilot-link.
Comment 71 Lenny G. Arbage 2008-01-24 01:30:02 EST
when hotsync is active on the clie, I do get
Bus 003 Device 006: ID 054c:0066 Sony Corp. Clie PEG-N7x0C/PEG-T425 PalmOS PDA
Serial

via lsusb.  no pilot-xfer love, however, via "pilot-xfer -p usb: -l" (as root or
other).

The fallback visor mode does work when I follow the pilot-link README.fedora
instructions, so that's what I'll use for now.

Should I try to debug further with upstream libusb?

Comment 72 Kevin R. Page 2008-01-24 03:15:05 EST
(In reply to comment #71)
> The fallback visor mode does work when I follow the pilot-link README.fedora
> instructions, so that's what I'll use for now.
> Should I try to debug further with upstream libusb?

Yes, if you can, perhaps you could ask on the pilot-link list whether this
device is expected to work with libusb. I note - without fully knowing what it
does - that a different Clie model recently had a USB_INIT_SONY_CLIE flag set in
the pilot-link USB code to fix timing issues. This is not set for your Clie.
Perhaps it's something similar?

If you get anywhere (or not!) you might like to file a separate Fedora bug
regarding pilot-link libusb compatibility with the Clie SJ20 - it's a bit
off-topic here (maybe leave a cross-reference).
Comment 73 Alex Lancaster 2008-01-24 03:58:37 EST
If the pilot-link currently in updates-testing works for you (or does not work),
consider adding a note and/or a "works for me" (or "doesn't work" as
appropriate) on:

https://admin.fedoraproject.org/updates/F8/FEDORA-2008-0453

Please only leave short notes, detailed bug reports should go here (or on bug
# 	280251, depending on what is appropriate).
Comment 74 Daniel Challen 2008-02-27 11:22:32 EST
(In reply to comment #58)
> To add to this Joe, for any given Palm device, the correct device node will be
> either /dev/ttyUSB0 or 1 and it will be fixed for that device (i.e. any Z22 will
> always need that same device node linked to /dev/pilot) and this will also be
> the case for where /dev/ttyUSB2 and 3 are created, the correct one will always
> be /dev/ttyUSB(n+2) where n is 0 or 1 as described above. As an unsubstantiated
> comment, I think that most USB Palms use /dev/ttyUSB1 these days, but the
> Tungsten T used /dev/ttyUSB0 for some reason.
Actually, not *quite*. If /dev/ttyUSB0 already exists, say for a PocketPC device
(yes, I have both PocketPC and Palm devices here) then the Palm device will get
the next available ttyUSB? instances. It is true that a given device will always
 try to Hotsync through the 1st or 2nd of the /dev/ entries that it is assigned,
but which /dev/ entries are assigned can never be relied upon. E.g. my Palm TX
will normally be assigned /dev/ttyUSB{0,1} and 'talk' Hotsync through
/dev/ttyUSB1, however if I've plugged in a PocketPC device beforehand, it will
get /dev/ttyUSB{1,2} and so Hotsync on /dev/ttyUSB2. If I disconnect and
reconnect I see that /dev/ttyUSB{1,2} are still in use, so the device gets
/dev/ttyUSB{3,4} in which case I should Hotsync on ttyUSB4. Udev rules work with
many devices for setting the /dev/pilot symlink because those devices always use
the *first* of the two visor ttyUSB? entries. Not so for the TX.

I have gotten the TX to sync with both command line tools and Gnome-pilot using
both visor and libusb but the second method is much more prone to timing
problems (chowning the /proc/bus/usb/ entry at the right time)
Comment 75 Bug Zapper 2008-05-14 07:57:18 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 76 Bug Zapper 2008-06-16 21:10:30 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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