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