Bug 186548 - gpilotd init dialog doens't continue after new user installation on treo650
gpilotd init dialog doens't continue after new user installation on treo650
Product: Fedora
Classification: Fedora
Component: gnome-pilot (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Malcolm
: 186402 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-03-24 05:45 EST by Bowe Strickland
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

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

Attachments (Terms of Use)
strace of gpilotd when exhitbiting above behavior (77.51 KB, text/plain)
2006-03-24 05:45 EST, Bowe Strickland
no flags Details

  None (edit)
Description Bowe Strickland 2006-03-24 05:45:52 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
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.
Comment 1 Bowe Strickland 2006-03-24 05:45:52 EST
Created attachment 126617 [details]
strace of gpilotd when exhitbiting above behavior
Comment 2 Nigel Metheringham 2006-03-26 07:44:48 EST
*** Bug 186402 has been marked as a duplicate of this bug. ***
Comment 3 Nigel Metheringham 2006-03-26 07:53:32 EST
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).

Comment 4 Nigel Metheringham 2006-03-26 07:58:04 EST
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.
Comment 5 Matt Davey 2006-03-27 08:06:04 EST
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.
Comment 6 Nigel Metheringham 2006-03-27 09:30:50 EST
Setting timeout to zero does appear to work as a workround.

Will look at other patch.
Comment 7 Bowe Strickland 2006-04-21 15:08:31 EDT
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:
Comment 8 Nigel Metheringham 2006-04-22 10:38:40 EDT
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).
Comment 9 Bowe Strickland 2006-04-24 09:55:02 EDT
thanx for timeout pointer... 

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