Description of problem: No USB Palm/pilot-link related connectivity appears to work in FC4. Version-Release number of selected component (if applicable): pilot-link-0.12.0-0.pre3.0.fc4.1 kernel-2.6.11-1.1369_FC4 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:- pilot-link-0.11.8-8.i386.rpm kernel-2.6.11-1.27_FC3.i686.rpm 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:- http://forums.fedoraforum.org/showthread.php?t=56246 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).
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 work. 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]
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.
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 usbserial_generic 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.
is your Palm connected to usb-hub? if yes, please try to connect it directly to your computer. Does it work?
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.
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" kernel-2.6.11-1.1369_FC4 pilot-link-0.12.0-0.pre3.0.fc4.1 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).
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.
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 "high". 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 again." 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 /var/log [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. David
Created attachment 115951 [details] Output of "cd /var/log ; diff -U1 rpmpkgs.2 rpmpkgs" showing rpm changes between times working HotSync & today's failure.
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 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0d000 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, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x264000 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, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xbe9000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000 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 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0c000 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.
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
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.
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.
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). investigating...
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 - http://bugzilla.gnome.org/show_bug.cgi?id=274032 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)
(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... Aah... 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.
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 http://aeolis.gps.caltech.edu/pilot-link/ 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?
Pending this getting fixed, I posted a workaround that worked for me on a thread on fedora-devel-list: http://www.redhat.com/archives/fedora-devel-list/2005-June/msg01389.html 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): #!/bin/sh 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: KERNEL="ttyUSB1",SYMLINK="pilot" to: /etc/udev/rules.d/10-local.rules 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.
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?
Than, 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] Doing 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....
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.
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.
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? David
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.
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). David
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 http://www.bytebot.net/blog/archives/2005/07/04/im-just-a-kid
FWIW: 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 pilot-link-0.12.0-0.pre4.2 pilot-link-devel-0.12.0-0.pre4.2 jpilot-0.99.8-0.pre9.1 [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).
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? Rob
FWIW: problem persists under 2.6.12-1.1398_FC4 for me.
Hi, 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 cheers, john
Ngo, 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.
Bug #158809 from FC4test3 seems to be the udev bug description which causes this pilot synchronization failure. It seems not to be solved.
yep, it's exactly the same - these two should be merged
*** This bug has been marked as a duplicate of 158809 ***