Re: z22 F7 problem

[Tom Billiet <mouse256 ulyssis org>]

----- Original Message -----
From: Matt Davey
Time: 30-09-07 12:47
> 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/$$
> 

This is also the only thing I can do.

> 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).

Yeah, I was one of these users. I will summarize what I've found out
about this.

With the previous kernel:
-) At the moment I connect my palm, ttyUSB0 and ttyUSB1 are created
-) gpilotd starts printing the "using net TRUE" lines
-) after 2 seconds, gpilotd gives a timeout message (I have to wait for
this, otherwise sync did not work)
-) I hit the hotsync button, ttyUSB0 and ttyUSB1 are destroyed, ttyUSB2
and ttyUSB3 are created
-) gpilotd is starting

With the current kernel:
-) At the moment I connect my palm, ttyUSB0 and ttyUSB1 are created
-) gpilotd starts printing the "using net TRUE" lines
-) no more timeout message arrives
-) I hit the hotsync button, ttyUSB0 and ttyUSB1 are destroyed, but
again *ttyUSB0* and *ttyUSB1* are created
-) gpilotd does nothing, palm times out

I think the problem lies there that gpilotd keeps listening on an old
usb connection that doesn't exist anymore, but I don't know who is
responsible for this fault: kernel, udev, pilot-link or gpilotd?

>[...]
>>    - 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.

Same kernel, same palm, same problems
> 
> 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.

Downgrading the kernel is not that easy on my linux version (archlinux),
so I can't test that...

Tom