Okay, taking a closer look, those lines are just showing that there's a
gap between the usb device being detected and the creation of the
/dev/pilot symlink. At the end of the output we can see the 'poll',
which means we've found /dev/pilot and are trying to talk.
We've made some progress. The PDA crash does seem to be caused by some
internal pilot-link code that sends some unexpected data to the PDA.
I'm not entirely clear of the history of this code, but it appears to be
an attempt to workaround some problems with udev device creation on
linux :(
We're getting down to a fairly low level here, but it might be useful to see:
1. the pilot-link debugging for the 'timeout=0' gnome-pilot case, and the
normal pilot-xfer case.
2. the strace output you get from gpilotd on the timeout=2 case. Run 'strace
gpilotd'. It'll
produce a long output. What I want to see is whether the 'poll' actually
returns a timeout,
or some error.
As for workarounds, it might be worth seeing if you can set up a direct
'libusb' connection:
http://code.pilot-link.org/README.libusb
once you've got it working for pilot-xfer, you just set the usb device in
gnome-pilot to 'usb:' and hey presto, you don't need the visor module anymore.
--
gpilotd locks up my Palm Z22
https://launchpad.net/bugs/66355
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
