Red Hat Bugzilla – Bug 186548
gpilotd init dialog doens't continue after new user installation on treo650
Last modified: 2007-11-30 17:11:28 EST
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)
How reproducible: very
Steps to Reproduce:
1. install pilot applet
2. choose USB, never synced before in initial dialog
3. push sync on treo650
treo completes hotsync happily, but dialog never activates "Forward" button
dialog should allow me to continue to configure conduits
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
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
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:
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:
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
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...