Bug 161058 - Palm support apparently broken in FC4
Palm support apparently broken in FC4
Status: CLOSED DUPLICATE of bug 158809
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-06-20 07:03 EDT by Nigel Metheringham
Modified: 2007-11-30 17:11 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-04 02:17:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output of "cd /var/log ; diff -U1 rpmpkgs.2 rpmpkgs" showing rpm changes between times working HotSync & today's failure. (20.98 KB, text/plain)
2005-06-24 16:05 EDT, David Kewley
no flags Details

  None (edit)
Description Nigel Metheringham 2005-06-20 07:03:31 EDT
Description of problem:
No USB Palm/pilot-link related connectivity appears to work in FC4.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Hit hotsync on USB connected Palm
2. Wait for kernel/udev to sort devices (this takes much longer than before)
3. pilot-xfer -p /dev/ttyUSB1 -l
Actual results:
 Hang or error:-
   Listening to port: /dev/ttyUSB1

   Please press the HotSync button now...
   Error accepting data on /dev/ttyUSB1

Expected results:
 List of databases

Additional info:
 Worked OK on FC3:-

Testing with a Treo 650 (USB Id 0830:0061), however also tried, with the same
results on a old Tungsten T (USB Id 0830:0060) with the same results.

Have seen other reports of problems with Treo:-

However not many - presumably the Palm is now a dead duck, and the pilot link
set spending their time playing with a Web CMS is not helping :-(

Tried pulling source for pilot-link 0.12.0 pre4 and building.  This fails with
same symptoms but different messages (only tested this against Treo 650).
Comment 1 Nigel Metheringham 2005-06-20 08:10:36 EDT
Tried some more tests.  Now more confused.

Dropping back to the FC3 pilot-link package (pilot-link-0.11.8-8) and the
process still doesn't work.
Dropped back to the FC3 errata kernel (kernel-2.6.11-1.27_FC3) as well, also not

udev settings look OK, devices are creating OK, and with usable permissions.
Occaisionally seen error message from kernel:-
  usb 2-1.4: pilot-xfer timed out on ep0in

Box was updated from FC3 to FC4 using anaconda from CD.  All palm functionality
was OK before update.  Palm USB works after update (can mount palm device as
filesystem using another piece of software).  Detection of device when
hotsyncing, and creation of udev devices looks OK.

[I'm away for a few days now so will not be able turn round queries quickly]

Comment 2 Ngo Than 2005-06-20 10:26:42 EDT
could you please attach the output of dmesg or /var/log/messages after pilot-xfer 
has failed. Thanks

please take a look at http://fedoranews.org/tchung/gnome-pilot/ and make sure
that the device should exist before connecting.
Comment 3 Glenn W. Bach 2005-06-20 13:28:18 EDT
I see exactly the same problem, except with a Treo 600. The devices are created
properly, but pilot-xfer (or jpilot, gnome-pilot...) just sit there and never
seem to make a connection. This is also on a system that worked on FC3. I
re-installed rather than upgraded, so it is a clean system. I understand the
udev issues required to get the permissions correct, and the devices have the
appropriate permissions. It also fails if I run pilot-xfer as root.

/var/log/messages show the following as I start hotsync on the palm:

Jun 20 10:21:33 dhcp-152-165 kernel: usb 2-1: new full speed USB device using
uhci_hcd and address 2
Jun 20 10:21:35 dhcp-152-165 kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for Generic
Jun 20 10:21:35 dhcp-152-165 kernel: usbcore: registered new driver
Jun 20 10:21:35 dhcp-152-165 kernel: usbcore: registered new driver usbserial
Jun 20 10:21:35 dhcp-152-165 kernel: drivers/usb/serial/usb-serial.c: USB Serial
Driver core v2.0
Jun 20 10:21:35 dhcp-152-165 kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for Handspring Visor / Palm OS
Jun 20 10:21:35 dhcp-152-165 kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for Sony Clie 3.5
Jun 20 10:21:35 dhcp-152-165 kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for Sony Clie 5.0
Jun 20 10:21:35 dhcp-152-165 kernel: visor 2-1:1.0: Handspring Visor / Palm OS
converter detected
Jun 20 10:21:35 dhcp-152-165 kernel: usb 2-1: Handspring Visor / Palm OS
converter now attached to ttyUSB0
Jun 20 10:21:35 dhcp-152-165 kernel: usb 2-1: Handspring Visor / Palm OS
converter now attached to ttyUSB1
Jun 20 10:21:35 dhcp-152-165 kernel: usbcore: registered new driver visor
Jun 20 10:21:35 dhcp-152-165 kernel: drivers/usb/serial/visor.c: USB HandSpring
Visor / Palm OS driver v2.1

Nothing else show up when I run pilot-xfer, which just sits there.

Comment 4 Ngo Than 2005-06-22 06:28:45 EDT
is your Palm connected to usb-hub? if yes, please try to connect it directly to
your computer. Does it work?
Comment 5 Glenn W. Bach 2005-06-22 12:21:05 EDT
No, I wanted to reduce the variables, so I plugged the cradle in directly to the
system, and then I tried just a cable plugged in directly. Both arrangements
gave the same results.
Comment 6 Patrick J Kobly 2005-06-23 13:27:59 EDT
Another datapoint...  I'm using a Palm Tungsten E, and get the same behaviour,
except w/o "Error accepting data on /dev/ttyUSB1" and no "usb 2-1.4: pilot-xfer
timed out on ep0in"


Same behaviour whether the device is connected to hub or not.  Had previously
had 2 or 3 successful syncs with the device.  No config changes and the device
no longer works.

I am willing to provide assistance debugging (incl. during working hours).
Comment 7 Glenn W. Bach 2005-06-24 14:28:27 EDT
I working on a test system, so I can replace libraries or change kernels or
whatever if it would help. I also don't see the error messages about accepting
data and time out, it just never connects.
Comment 8 David Kewley 2005-06-24 16:01:28 EDT
Here's some good data for you that shows that this is a very recent problem,   
and is not specific to USB.   
This bug is fairly critical to me (and to many other users, I imagine),   
because I have no other easy way to backup my Palm, its batteries are   
beginning to run low, and it loses all databases when the batteries are   
changed (even if the old ones still have life).  If I don't back it up soon, I   
risk losing the last 11 days of data.  I suggest this bug's severity be set to 
I have a Palm m100 (a cheap model, about 3 years old) whose sync cable is   
serial rather than USB.  Syncs worked fine on FC2 using pilot-link cli tools   
as well as jpilot & kpilot.   
Syncs also worked fine under FC4t3, and maybe even with the initial FC4   
release, but they do *not* work now with any of the three above-mentioned   
tools on this nearly-FC4 machine (see below and following attachment for rpm   
details & update timing).   
Here is what happens with my version of the simple pilot-link command that is   
given in the bug-opening comment:   
[kewley@aeolis nfs]$ pilot-xfer -p /dev/pilot -l   
   Listening to port: /dev/pilot   
   Please press the HotSync button now... connected!   
   Reading list of databases in RAM...   
   List complete. 0 files found.   
   Thank you for using pilot-link.   
The time between pressing the HotSync button on the sync cable and the   
"connected!" is just under a second.  It then pauses for just over 20 seconds   
before dumping the rest of the messages & exiting.  During the pause, the Palm   
screen says "Identifying user", which I've never seen before, so it may be   
something that normally flashes by quickly & routinely.  The palm continues   
showing this screen for a few more seconds before putting up its own alert box   
that says, "The connection between your handheld computer and the desktop was   
lost. Some of your data was NOT backed up. Please check your setup and try   
This is on hardware, software, and configuration that was last successfully   
used to do a sync with kpilot (& I believe jpilot) on 6/13/05.  The only thing   
that has changed in the last 11 days, as far as I can determine, is a huge   
slew of rpm updates.   
This machine itself was a clean install of FC4t3, frozen when rawhide   
branched, then updated using yum to FC4 official.  The Palm itself tells me   
that the last successful HotSync operation was on 6/13; that would have been   
on this same desktop machine.  Here is some interesting information on the   
rpms installed (remember, syncs *worked* up to at least 6/13!).   
[kewley@aeolis log]$ pwd   
[kewley@aeolis log]$ ls -al rpm*   
-rw-r--r--  1 root root 68744 Jun 24 04:04 rpmpkgs   
-rw-r--r--  1 root root 69975 Jun 18 04:20 rpmpkgs.1   
-rw-r--r--  1 root root 69245 Jun 11 04:02 rpmpkgs.2   
-rw-r--r--  1 root root 69080 Jun  4 04:03 rpmpkgs.3   
-rw-r--r--  1 root root 69081 May 28 10:21 rpmpkgs.4   
See the attachment I'll make next for the output of   
  diff -U1 rpmpkgs.2 rpmpkgs   
which should show you what rpms changed between the last successful HotSync   
and today's failures.   
/var/log/messages shows nothing relevant; remember that mine is a serial  
device, so you wouldn't expect to see hotplug events.  
Comment 9 David Kewley 2005-06-24 16:05:10 EDT
Created attachment 115951 [details]
Output of "cd /var/log ; diff -U1 rpmpkgs.2 rpmpkgs" showing rpm changes between times working HotSync & today's failure.
Comment 10 Keith McDuffee 2005-06-24 16:32:08 EDT
I tried rebuilding the source packages of pilot-link-0.11.8-8, which is FC3's
version, and it seems to behave the same (i.e., doesn't work). So I'm thinking
this is a kernel issue.

Also, here's an strace on 'pilot-xfer' (the FC4 version), if it helps at all:

[root@daedalus tmp]# strace pilot-xfer -p /dev/pilot -b .
execve("/usr/bin/pilot-xfer", ["pilot-xfer", "-p", "/dev/pilot", "-b", "."], [/*
24 vars */]) = 0
brk(0)                                  = 0x8646000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=103890, ...}) = 0
old_mmap(NULL, 103890, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ef3000
close(3)                                = 0
open("/usr/lib/libpopt.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\342"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=30712, ...}) = 0
old_mmap(0x25d000, 32208, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x25d000
old_mmap(0x264000, 4096, PROT_READ|PROT_WRITE,
close(3)                                = 0
open("/usr/lib/libpisock.so.9", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \32\30"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=214604, ...}) = 0
old_mmap(0x417c000, 216128, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x417c000
old_mmap(0x41ad000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x30000) = 0x41ad000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\n_\255"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1489572, ...}) = 0
old_mmap(0xac1000, 1219548, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xac1000
old_mmap(0xbe5000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x124000) = 0xbe5000
old_mmap(0xbe9000, 7132, PROT_READ|PROT_WRITE,
close(3)                                = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ef29e0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xbe5000, 8192, PROT_READ)     = 0
mprotect(0xab9000, 4096, PROT_READ)     = 0
munmap(0xb7ef3000, 103890)              = 0
brk(0)                                  = 0x8646000
brk(0x8667000)                          = 0x8667000
stat64(".", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=36864, ...}) = 0
open("/dev/null", O_RDWR)               = 3
open("/dev/pilot", O_RDWR|O_NONBLOCK)   = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
fcntl64(4, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(4, F_SETFL, O_RDWR)             = 0
dup2(4, 3)                              = 3
close(4)                                = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
write(1, "\n", 1
)                       = 1
write(1, "   Listening for incoming connec"..., 54   Listening for incoming
connection on /dev/pilot... ) = 54
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {B9600 -opost -isig -icanon -echo ...}) = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "\1", 1)                        = 1
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "\377\0\0\0\26", 6)             = 5
select(4, [3], NULL, NULL, NULL

Then it just hangs there.
Comment 11 Keith McDuffee 2005-06-24 16:33:43 EDT
Addition to the strace in my last post. If I cancel out of the sync on the Palm
or if it times out, strace unsticks and I get this repeating over and over:

read(3, "", 1)                          = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "", 1)                          = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "", 1)                          = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "", 1)                          = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "", 1)                          = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "", 1)                          = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "", 1)                          = 0
Comment 12 Patrick J Kobly 2005-06-24 19:02:04 EDT
no RPM changes b/w success and failure for me.  Was running stock
(pilot-link-0.12.0-0.pre2.0) off of RC4 release CD's, got a successful backup,
tried to sync a little later, got hang.  Tried upgrading to pre3, same
behaviour.  Unfortunately, I never did try to sync the device during the short
time I was using FC3, so I don't have a comparison point there.
Comment 13 Nigel Metheringham 2005-06-27 17:04:34 EDT
I'm tending to the view that this is kernel (or just possibly hotplug/udev)
related rather than pilot-link.

I took the pilot-link-0.12.0-0.pre3.0.fc4.1 binary package to a FC3 system with
stock kernel (kernel-2.6.11-1.27_FC3.i586.rpm also
kernel-2.6.11-1.35_FC3.i586.rpm) and got pilot-xfer -l to work OK

I have not been able to get any version of pilot-link, RH supplied or
self-built, to work on FC4 using the stock kernel.  I also could not make it
work with the FC3 kernel forced onto a FC4 box, however that might be down to
hotplug/udev problem and the test set I did with the FC3 kernel was very short.
 I also tried a static linked (built on FC3) pilot-xfer on FC4 (stock kernel) to
eliminate other (C) library problems - this also failed to work.

Have queried Dave Jones to see if there are any potentially relevant USB/visor
module changes between the appropriate kernel revisions.

As another, confusing, data point, I was unable to get pilot-xfer to work on my
FC3 build box.  That box is SMP, all others tested were UP which could be
related there....

I'm grasping at straws here.  However I have no convinced myself that the
problem is outside the pilot-link package so we need to be looking at the rest
of the environment.
Comment 14 Patrick J Kobly 2005-06-27 17:18:44 EDT
OK...  Pursuing this a little bit further...  I can get pilot-xfer to work if:
pilot-xfer gets executed _very_ shortly after the dev files are created... ie. 
 If in a shell, I keep hitting up-arrow enter (with 'pilot-xfer -p /dev/visor1
--list' as my most recent command), it will connect and do the list.  If,
however, I let it sit for a second or two after the devices appear, pilot-xfer
will hang (tho' the Tungsten still says it's trying to connect).

attaching gdb to the hung process shows it hung in a select in unixserial.c
(libpisock.so) s_poll (the first select - no timeout).

Comment 15 Nigel Metheringham 2005-06-27 17:28:42 EDT
A journey through bugzilla shows up these:-
 - kernel bug#160926 - basically unhelpful
 - gnome-pilot bug#156646 - mixed set, looks potentially useful
 - gnome-pilot bug#160278 - mainly down to udev/gnome-pilot permissions and timing
 - Gnome bugzilla bunch of patches -

Some people appear to have at least jpilot/pilot-xfer working on FC4.  So we are
looking at:-
 - udev/hotplug bug/config-problem
 - strange hardware
 - timing maybe (creating the devices on FC4 is sooooo slow compared to FC3)
Comment 16 Nigel Metheringham 2005-06-27 17:31:39 EDT
(In reply to comment #14)
> OK...  Pursuing this a little bit further...  I can get pilot-xfer to work if:
> pilot-xfer gets executed _very_ shortly after the dev files are created... 


How about if you use mknod to create your very own static /dev/ttyUSB1
equivalent?  I did note in a couple of my other comments that udev is slightly
slower than treacle in January in northern Canada on FC4.

Will test tomorrow.
Comment 17 David Kewley 2005-06-28 02:09:28 EDT
I have got it working on my setup.  The key was to use the FC4t3 pilot-link   
instead of the FC4 version.   
I tried two older kernels (1363 and 1341) to no avail.  I then noticed that I   
had two pilot-link rpms -- x86_64 and i386.  I'm not sure how they both ended   
up getting installed (I originally installed this machine as FC4t3).  I   
deleted them both with --nodeps, then did a 'yum install pilot-link.x86_64).    
HotSync still didn't work (with the latest pilot-link), so I did a downgraded   
to the pilot-link version in FC4t3: pilot-link-0.12.0-0.pre2.0.  This last   
change is what made both pilot-link and kpilot work (and, I would presume, all   
the other apps that depend on pilot-link).   
It looks like FC4t3 repositories have been removed; I only was able to do this   
downgrade because I still have the FC4t3 install DVD, from which I could grab   
the older pilot-link rpm.  The DVD has both i386 and x86_64 rpms on it; I've   
put them up at   
for anyone who wishes to try them.  Note that you need to do 'rpm --oldpackage   
-F' to downgrade to these packages on a FC4 machine.  I can only vouch for the   
x86_64 rpm, but I presume the i386 rpm should work equally well on that arch.  
Also, the keys used to sign these packages may not already be imported into  
your rpm database; before you can install these packages, you should install  
the fedora test key:  
  rpm --import /usr/share/doc/fedora-release-4/RPM-GPG-KEY-fedora-test  
If others verify that this downgrade works for them, could the FC4 official 
packages please be fixed and updates released? 
Comment 18 Alex Lancaster 2005-06-28 07:31:40 EDT
Pending this getting fixed, I posted a workaround that worked for me on a thread
on fedora-devel-list:


Basically for pilot-link (and/or downgrade to use pilot-link-0.11.8 from FC3)
try using this wrapper script for pilot-link (e.g in ~/bin/pilot-link):

echo "Waiting for hotsync button"
until [ -e /dev/pilot ]; do sleep 1; done
exec /usr/bin/pilot-xfer "$@"

I used the udev facility for creating the symlink to /dev/pilot by adding the line:




This does not work 100% of the time but it can get around the extra latency in
loading the device that appears to present in FC4 over FC3.
Comment 19 Ngo Than 2005-06-28 11:14:19 EDT
It seems a problem in kernel-2.6.11-1.1369_FC4. I have tried to boot
kernel-2.6.11-1.35_FC3 on FC4. It works without any problem with
pilot-link-0.12.0-0.pre3.0.fc4.1, tested with T5.

Could someone please try this step?
Comment 20 Nigel Metheringham 2005-06-28 12:04:26 EDT

I don't fully understand what you are asking for.  I have just retried this with
kernel-2.6.11-1.1369_FC4 on my laptop, and using a script similar to the one
above in comment #18 and pilot-xfer -p /dev/pilot -l and it does not work for
me.  It also takes 8 seconds consistantly from the point where the hotsync
button is pressed to udev getting /dev/pilot into place.

[The kernel messages from the visor module appear in less than 1 second, lsusb
can see it within one second]

   mknod /tmp/pilot c 188 1

and then 
   pilot-xfer -p /tmp/pilot -l

(either before or a few seconds after pressing the hotsync button) works fine
for me.

For me the problem definitely seems to be somewhere in the hotplug/udev/hal
jungle.  I would suggest re-assigning this bug to one of those categories but I
am not sure where....
Comment 21 Ngo Than 2005-06-28 12:08:39 EDT
i mean, you should install the kernel-2.6.11-1.35_FC3 package on FC4 (with
--nodeps --force) and try to boot this kernel.

Comment 22 Nigel Metheringham 2005-06-28 12:49:27 EDT
Works better using kernel-2.6.11-1.35_FC3 - the time between start of hotsync
and udev getting the devices into place appears to be 2 seconds (cf 8 seconds in
comment #20 above).

Its still a bit of a case of you need to fire pilot-xfer in the right 2 or 3
second window, but at least the window is there after the devices are put in
place :-)

NB the differences between these 2 runs, other than the kernel, is that I had
fewer other things running in my desktop session.  I tried starting up the other
programs, but I did not have a few hours worth of history in evolution, firefox
etc, just new invocations started up.
Comment 23 David Kewley 2005-06-28 13:06:16 EDT
Everyone else (with USB sync cables I suppose) seems to be focussing on the 
kernel and udev etc., and can sorta fix the issue without downgrading 
pilot-link.  Perhaps my issue with serial cable is different, since it appears 
to have been solved by downgrading pilot-link one release (see comment 17). 
Shall I file a different bug so that we serial users don't get forgotten?  Or 
is no one else with a serial cable seeing the problem I saw? 
Comment 24 Patrick J Kobly 2005-06-28 14:23:42 EDT
downrev'd as requested.  Speeds the creation of devices fairly significantly. 
The window is still there, but appears to be a fair bit wider.  This is a bug
that should be fixed, regardless.

However, trying to sync via kpilot causes an Oops and hangs the pilot at
"Identifying user".  At this point, visor / usbserial / whoever's responsible
doesn't update its refcnt, because visor module has a refcnt of 1, while lsof
reports nobody's got either of the ttyUSB's open.
Comment 25 David Kewley 2005-06-28 15:19:19 EDT
Re: comment 24: Patrick, did you downrev the kernel or pilot-link? 
For me, kpilot does *not* oops after downreving pilot-link.  jpilot *does* 
oops after downrev (glibc catching a multiple free, as I recall).  Before 
downreving, my Pilot would hang (for 30-40 seconds) on "Identifying user" just 
like yours did, if I use either pilot-xfer (or kpilot, I believe). 
Comment 26 Nigel Metheringham 2005-07-05 04:41:43 EDT
Retested with errata kernel kernel-2.6.12-1.1387_FC4

Still fails to work at all for me under normal circumstances (I think I can make
it work in single user or very restricted modes - ie nothing else running etc,
and its a very tight window to hit the point where it will sync after the
devices are created).

It does work with a statically created device - I may put a udev rule in for
this instead.

I note some people appear to have this working without problem - eg
Comment 27 Patrick C. F. Ernzer 2005-07-06 05:23:14 EDT
with kernel-2.6.11-1.35_FC3 I can use jpilot and/or pilot-link reliably
with kernel-2.6.12-1.1387_FC4 I managed to do a "pilot-xfer -b 2005-07-06" once
after boot but not since. No idea if I miss the 2-3 second window repeatedly
(doubtful, see my udev rule further down).

relevant data:
[pcfe@a84-231-4-164 tmp]$ rpm -qa|grep pilot

[pcfe@a84-231-4-164 tmp]$ cat /etc/udev/rules.d/20-pilot.rules
BUS="usb", SYSFS{product}="palmOne Handheld*", KERNEL="ttyUSB[13579]",
SYMLINK="pilot", PROGRAM="/usr/bin/play /usr/share/sounds/info.wav"
#BUS="usb", SYSFS{product}="Palm Handheld ", KERNEL="ttyUSB1", SYMLINK="pilot"
#BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB*",
NAME{ignore_remove}="pilot", MODE="666"
#BUS="usb", SYSFS{product}="palmOne Handheld*", KERNEL="ttyUSB*",
NAME{ignore_remove}="pilot", MODE="666"
#BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB[13579]",
SYMLINK="pilot", PROGRAM="/usr/bin/play /usr/share/sounds/info.wav"
#BUS="usb", SYSFS{product}="Palm Handheld ", KERNEL="ttyUSB1", SYMLINK="pilot",
PROGRAM="/usr/bin/play /usr/share/sounds/info.wav"

As you can see I did a fair bit of playing with the udev rule and have setteled
on one that makes a sound when it's done (so that I know when to initiate
hotsync on the software side).
Comment 28 Rob van Vliet 2005-07-11 19:14:57 EDT
I can see the following behavior:

I have a file /etc/hotplug/usb/visor containing one line:
/bin/su - rob -c "/bin/date >> ~/.jpilot/sync.log ; /usr/local/bin/jpilot -s"

This causes jpilot to sync when I press the hotsync button, and the time to be
written to a log file.

The logfile looks suspicious. Here's an excerpt:

Mon Jul 11 07:50:54 CEST 2005
Mon Jul 11 07:50:56 CEST 2005
Mon Jul 11 08:12:41 CEST 2005
Mon Jul 11 08:12:43 CEST 2005
Mon Jul 11 22:39:16 CEST 2005
Mon Jul 11 22:39:18 CEST 2005
Tue Jul 12 00:43:48 CEST 2005
Tue Jul 12 00:43:49 CEST 2005

As you can see the kernel starts the script _twice_ every time I press the
hotsync button.

Indeed, jpilot reports
Syncing on device /dev/pilot
Press the HotSync button now
J-Pilot: sync PID = 4013
J-Pilot: press the hotsync button on the cradle or "kill 4013"
Username is etc...

which is the same behavior of the logfile.

Can anyone confirm this?

Comment 29 Patrick C. F. Ernzer 2005-07-18 02:33:23 EDT
FWIW: problem persists under 2.6.12-1.1398_FC4 for me.
Comment 30 John Rosauer 2005-07-26 00:11:26 EDT

It is _definitely_ caused by the HUGE DELAY between starting the
"hotsync", which effectively connectes the USB device, and the creation
of the /dev devices (ttyUSB[01] in my case).

On my machine it takes over 5 seconds!  And in that time my palm
device has long since given up trying to talk, which results in
pilot-xfer waiting forecever agfter it has opened the /dev/ttyUSB1.

I am running kernel-2.6.12-1.1398_FC4


Comment 31 Nigel Metheringham 2005-07-26 05:10:11 EDT

The major major part of this problem definitely appears to be in the
kernel/hotplug/udev layer, and the excurciating time it takes to make device
nodes available.

So how do we take this forward:-
  - reasssign this bug (and to which component)
  - new bug, make this a dependancy
  - something else

I can't see any relevant udev/hotplug bugs, and nothing that looks right in the
huge mass of kernel bugs.
Comment 32 Rodolfo Alcazar 2005-08-03 15:07:21 EDT
Bug #158809 from FC4test3 seems to be the udev bug description which causes this
pilot synchronization failure. It seems not to be solved.
Comment 33 John Rosauer 2005-08-04 00:47:26 EDT
yep, it's exactly the same - these two should be merged
Comment 34 Dave Jones 2005-08-04 02:17:44 EDT

*** This bug has been marked as a duplicate of 158809 ***

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