Re: z22 F7 problem

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
_______________________________________________
gnome-pilot-list mailing list
gnome-pilot-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list