Re: z22 F7 problem

[Matt Davey <mcdavey mrao cam ac uk>]

Hi,

> We tried to use the pilot-xfer program and was able to successfully sync
> using the pilot-xfer command directly one time only:
> 
> pilot-xfer -p /dev/pilot -b /tmp/$$

Odd.  If it works one time only, this suggests to me there might
be a problem at the kernel/udev layer.  It doesn't seem credible
that there's a difference at the palm end, nor pilot-xfer.  That
leaves the usb hardware and udev.

If you browse the archives to this list over the last month
or two you will see several long threads discussing recent
regressions with Palm connectivity.  My current hunch is that
a relatively recent kernel change has messed up the timing
of device detection and creation.  This has happened before
(pretty badly about 18 months ago, IIRC).  There have been
reports of syncing only working if you start a sync about
a second before starting pilot-xfer or gnome-pilot (pause/unpause).

[...]
> The interesting thing is that we saw this sort of strange output with
> suspicious "Using net TRUE" lines from gpilotd:

You can ignore that.  It's an historical artifact: 'NET' refers
to one of several flavours of the palmos comms protocol.

[...] 
> We also found that the Treo 650 info was missing from
> /usr/share/gnome-pilot/devices.xml and had to be added. The chunk of text to
> add to that file was:
> 
>  <!-- Handspring Treo 650 -->
>  <device vendor_id="0830" product_id="0061" />

This vendor/product id pair is definitely in the devices.xml shipped
with gnome-pilot, and has been for years.  Note that the preceding
text ('handspring treo 650') is just a comment and has no function.

> At one point we tried an experiment: We changed "Cradle type" in the
> gpilotd-control-applet device settings from USB to Serial, and kept hitting
> the sync button, and one time it did seem to trick out gpilotd into sensing
> the device and starting the sync process correctly.  But I could not
> reproduce that result subsequently.

Curious, but probably just showing the sensitivity to timing mentioned
above.  Serial and usbserial (ie. visor module, not libusb) behave
very similarly under the hood.  What is different is the way in which
connections are established.  For serial, the device must exist when
you start gnome-pilot (if I remember correctly), so your test was
probably just a lucky example of starting gnome-pilot the right
fraction of a second before or after starting a sync.

> Versions of packages and their versions I'm using now (all installed via yum
> and none are compiled from source):
> 
>    - gnome-pilot-2.0.15-5.fc7
>    - pilot-link-0.12.2-4.fc7
>    - uname -a --> Linux 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:08:59 EDT
>    2007 x86_64 x86_64 x86_64 GNU/Linux

Of those three, I think the kernel is the most likely source of trouble,
unfortunately.

I don't have many suggestions, unfortunately.  I think the solution
will lie either with the resourceful pilot-link folks figuring out
more ways to deal with the problematic timing issues, or a fix
in the udev/kernel layers in a future kernel update.

You could try installing an additional kernel package and downgrading.
You can usually have multiple kernel packages installed and choose
between them at boot time.

Matt