Re: z22 F7 problem

Tom Billiet <[email protected]>
Newsgroups gmane.comp.gnome.apps.pilot
Message-ID <[email protected]>

----- 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.