Description of problem: Upon initial sync to treo650, gpilotd dialog "hangs" Version-Release number of selected component (if applicable): [root@... ~]# cat /etc/redhat-release ; uname -r; rpm -qa | grep -e libc -e pilot Fedora Core release 5 (Bordeaux) 2.6.15-1.2054_FC5 glibc-common-2.4-4 libcroco-0.6.1-1 glibc-devel-2.4-4 libcroco-devel-0.6.1-1 pilot-link-0.12.0-0.pre4.5.2.1 glibc-kernheaders-3.0-5.2 libcap-devel-1.10-24.2 glibc-2.4-4 libcap-1.10-24.2 pilot-link-devel-0.12.0-0.pre4.5.2.1 glibc-headers-2.4-4 gnome-pilot-2.0.13-7.fc5.4 gnome-pilot-devel-2.0.13-7.fc5.4 How reproducible: very Steps to Reproduce: 1. install pilot applet 2. choose USB, never synced before in initial dialog 3. push sync on treo650 Actual results: treo completes hotsync happily, but dialog never activates "Forward" button Expected results: dialog should allow me to continue to configure conduits Additional info: can pilot-link fine. strace -f -p <pid of gpilotd> attached.
Created attachment 126617 [details] strace of gpilotd when exhitbiting above behavior
*** Bug 186402 has been marked as a duplicate of this bug. ***
If debugging is put on for pilot-link (see README.debugging in pilot-link source doc directory - note that I am using DLP debugging which is not documented in that file) then you see:- ... DLP sd=17 dlp_ReadSysInfo DEV FLUSH unixserial flushed input buffer DEV TX unixserial wrote 6 bytes DEV TX unixserial wrote 8 bytes NET TX sd=17 type=1 txid=0x00 len=0x0008 0000 12 01 20 04 00 01 00 04 .. ..... DEV RX unixserial read 1 bytes NET RX (17): Checking for headerless packet 1 DEV RX unixserial read 5 bytes DEV RX unixserial read 8 bytes NET RX sd=17 type=1 txid=0x00 len=0x0008 0000 93 00 00 00 00 00 00 00 ........ dlp_exec: result CMD 0x13 doesn't match requested cmd 0x12 (gpilotd:17700): gpilotd-WARNING **: An error occured while getting the pilot's system data ... Whats happening here is that there is an extra response set in the input buffer which is either turning up after the input buffer is flushed before the ReadSysInfo command is sent OR the input flushing just doesn't work. As an experiment I tried modifying the pilot-link code for dlp_ReadSysInfo() to "suck" the input empty before sending the command. This makes the initial sync succeed at the expense of pausing during the process to suck the buffer dry. Fixing this needs to determine why this extra command input is in the stream and dealing with it, or fix the input flushing (or both).
Suggest change of summary to gpilotd fails to detect pilot name information I can reproduce this bug on a Tungsten C as well (although most testing is on a Treo 650). Its also a generic sync problem since this affects all sync types not just initial set up - the s/w is just failing to get the ReadSysInfo data.
Nigel, this is probably an instance of pilot-link bug 1585: http://bugs.pilot-link.org/1585 A quick workaround may be to configure a timeout of zero (but this may cause hangs for other reasons). The bug report contains a patch that 'works for me' but it hasn't yet been applied to pilot-link source, probably because no-one seems to know whether there are devices that require the code that I'm removing... Feedback here and at bugs.pilot-link.org would be good.
Setting timeout to zero does appear to work as a workround. Will look at other patch.
How do I set timeout to zero? At any rate, gnome-pilot-devel-2.0.13-7.fc5.6 seems to have resovled this, but now blocking at new point: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189627
Bowe, Timeout can be set in the gnome-pilot applet dialog. However if you are using the new package set with pilot-linux 0.11.x then this won't be an issue and timeout should be set to 2 to 5 seconds as per normal. [I also do not see a hang problem with 2.0.13-7.fc5.6 - the package from a couple of days earlier did have a crash/hang issue. Make sure you are actually running the version you think you are by logging right out and restarting your session] Can I suggest this bug be marked as dead in some way (its not exactly fixed - we have just backed out the later versions, and so we do need to make sure its nailed when the packages are next updated - hoever there is a new version of gnome-pilot for 0.12 now).
thanx for timeout pointer...