Pb syncing treo 650 on dapper drake

Thanks for your bug report. Can you check if the debs on http://daniel.holba.ch/ubuntu/gnome-pilot/ make it better for you? If so, this bug might be a duplicate of bug 25653

No, sorry... (:()

I've installed the debs, removed .gpilotd in my home, and made a reboot.

When I try to obtain my palm SYNC ID in the préférence page, my treo remain blocked, trying to connect to the computer.

Thanks for your help !

Hello,

Since my last report I've tried a lot of method exposed in numerous place on the web... (changing device.xml, adding a rule in /etc/udev etc...), with no success.

Does anyone know where can be the problem ? Gnome-Pilot seem to not function properly in dapper (as i saw on the web ...)

Can anybody help me ? (:)) Please, it's so awfull to have a Treo and cant synchronise it as i can in breezy... (:))

Thanks a lot,

I cannot use hotsync anymore, so for me it's critical (but perhaps, i'm not allowed to change the severity status, if so i apologize).

Same problem with Dapper. (Works fine with Breezy.)

Poppy, following this how-to solved the problem for me:
http://doc.gwos.org/index.php/Palm_sync_dapper

Note: changing the device port to "/dev/pilot" while keeping its type as "USB" was key to getting sync to work. (The device port and type can be changed just by clicking on the pilot panel applet, or by running "gpilotd-control-applet" from the command line.)

Hope this helps.

Sync is no longer working reliably for me on Dapper. Here's the log:

*** gpilotd log ***
gpilotd-Message: gnome-pilot 2.0.13 starting...
gpilotd-Message: compiled for pilot-link version 0.11.8
gpilotd-Message: compiled with [VFS] [USB] [IrDA] [Network]
gpilotd-Message: Activating CORBA server
gpilotd-Message: bonobo_activation_active_server_register = 0
gpilotd-Message: Watching Cradle (/dev/pilot)
gpilotd-Message: Found 4766, 0001
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0502, 0736
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 091e, 0004
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 082d, 0100
gpilotd-Message: Using net FALSE
gpilotd-Message: Found 082d, 0200
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 082d, 0300
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0c88, 0021
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0001
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0002
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0003
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0020
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0031
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0040
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0050
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0060
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0061
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0070
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0080
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 04e8, 8001
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 04e8, 6601
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0038
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0066
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0095
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 009a
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 00c9
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 00da
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 00e9
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0144
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0169
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 12ef, 0100
gpilotd-Message: Using net TRUE
gpilotd-Message: Client seems ok
gpilotd-Message: setting PILOTRATE=115200

(gnome-pilot:13394): gpilotd-WARNING **: Unable to bind to pilot
gpilotd-Message: setting PILOTRATE=115200

(gnome-pilot:13394): gpilotd-WARNING **: pi_accept_to: Input/output error

(gnome-pilot:13394): gpilotd-WARNING **: pi_accept_to: timeout was 0 secs
gpilotd-Message: setting PILOTRATE=115200
gpilotd-Message: Cradle Cradle has 0 events
gpilotd-Message: corba: orbed_notify_user, notifications->connect.size = 1, id = Treo-650
gpilotd-Message: Client appears to be disconnected...

(gnome-pilot:13394): gpilotd-WARNING **: orbit_daemon_glue.c:1494 Exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0

gpilotd-Message: removing monitor on Treo-650 for I...

This seems likely to be a kernel or udev problem; Scott, any idea?

Just a bit of clarification on my last post: syncing with a Treo 650 in the Dapper beta is working, just not reliably.

That is, sometimes syncing works flawlessly, sometimes it doesn't work at all (i.e., nothing happens), and sometimes I get the "invalid pointer" error shown in the log above.

I just keep killing -9 `pidof gpilotd`" and re-running it, until eventually, syncing suddenly works again.

Hope this is helpful.

I don't think this is either a kernel or udev problem from the report.

It makes it read like the USB pilot simply doesn't get switched on until the button on it is pressed.

Makes it sound like a gnome-pilot bug for believing otherwise.

The USB device for the Treo doesn't get turned on until the sync button is pressed. I think there's a USB trick where you can make /dev/pilot a link (hard link, maybe?) /dev/ttyUSB1 and leave it dangling when the device disconnects.

I'm having this same problem, and I've found it incredibly frustrating. My understanding is that the pilot protocol changed with the new devices, and pilot-link 0.12.x is needed to make the conversation work.

I've tried building the 0.12.x libs myself (fighting the crappy dpatch-based package... blech!) and never got them quite right. I'm resigned to waiting for this to get sorted out, but I'm guessing it won't be done in the Dapper timeframe.

I regret my snarky remark about dpatch. Sorry.

Hi, a couple of points from gnome-pilot.

The 'invalid free' bug has just been fixed in CVS. I don't know why it has only recently shown up (it was reported on fedora) as the problem code was rather old. Anyway, that's a straight bug.

Another problem has also been fixed, which may have caused some of the unreliability problems. Frank: do you find multiple /dev/ttyUSB* devices being created and hanging around? i.e. more than just the usual two? If so, you're affected by this bug, which again has been fixed in CVS.

Matt, I just saw your question (I assume it was addressed to me -- my name is spelled with a "z", not "k").

As of right now, with the latest Dapper Beta packages, only the usual two /dev/ttyUSB* are being created when I hit the sync button, and they disappear normally afterwards. I don't know if more than two ttyUSB* were being created prior to upgrading to the latest packages.

In any case, syncing still takes a couple of tries, though I'm no longer getting the "invalid pointer" error when it doesn't work; instead, the daemon just keeps trying to communicate with the Treo. Here's a snip from the log:

*** gpilotd log ***
gpilotd-Message: setting PILOTRATE=115200

(gnome-pilot:17104): gpilotd-WARNING **: pi_accept_to: Connection timed out

(gnome-pilot:17104): gpilotd-WARNING **: pi_accept_to: timeout was 3 secs
gpilotd-Message: setting PILOTRATE=115200

(gnome-pilot:17104): gpilotd-WARNING **: pi_accept_to: Connection timed out

(gnome-pilot:17104): gpilotd-WARNING **: pi_accept_to: timeout was 3 secs

... [these messages keep getting repeated until I interrupt the daemon.]

***

At least now I'm been able to stop the daemon with a normal kill i.e. without having to send it a SIGKILL. As before, syncing suddenly works fine after a couple of tries.

(sorry for misspelling your name, Franz...)

A couple more diagnostic tips:

have you tried the 'static device node' trick mentioned above? This basically means doing something like:
# mknod /dev/pilot c 188 1
# chmod 0660 /dev/pilot
# chown :uucp /dev/pilot
to create a /dev/pilot device node that behaves like ttyUSB1. This trick can prevent annoying timing problems caused by latency in udev device node creation.

do you get reliable behaviour with pilot-link? Try
pilot-xfer -p /dev/ttyUSB1 -l
If it works like a dream without any problems, then it's more likely to be a gnome-pilot problem. If it has trouble, chances are your problem lies elsewhere.

I have identical symptoms to Franz. I have a Palm Tungsten T.

I can successfully sync maybe 1 time in 20. All other times I receive output from gpilotd just like Franz' above. I have tried creating a hard /dev/pilot as suggested by Matt - the symptom persists, and then udev scripts tidy up /dev/pilot afterwards!

pilot-xfer also does not work reliably, nor does Jpilot.

I have built 0.12 pilot-link. If I have a hard link to /dev-pilot, pilot-xfer dies straight away with the message "Killed."

Otherwise, if I have not pressed the button, pilot-xfer says "Unable to bind to port: /dev/pilot". If I have pressed the button, pilot-xfer asks for me to press it again.

Timing is definitely an issue, but there is some other subtle problem, otherwise the hard link would work.

What version of pilot-link is shipping with Dapper?

For pilot-link 0.12, I have a couple more things to try out:

try using:
pilot-xfer -p usb: -l
(see thread here: http://www.pilot-link.org/pipermail/pilot-link-general/2006-April/002721.html)

Also, for gnome-pilot, try setting the 'timeout' to zero. You'll find the timeout parameter using the configuration applet, under the 'devices' editing dialog.

Hi, i'm wondering if #25653 is not a duplicate. My problems have some things in common with #25653, and some other with the current.
I have an IBM WorkPad c505 (rebranded Palm m505c, OS 4.0). I'm trying to connect with the USB cradle. Since i read #25653, i've been trying hard to figure what is wrong (see my comment for #25653).

Using "timeout 0" for gpilotd AND mounted /proc/bus/usb/ AND Daniel's gnome-pilot, i have been able to reach "authenticating user" on the device's screen, but no more.

in the same period of time, i've been able to run successfully "PILOTRATE=115200 pilot-xfer -p /dev/pilot -l" two times, but no more (i'm still strying but no luck).

(sorry for my bad english...)

I don't think I can help much more at this point as I'm not a Ubuntu user.

It sounds like it might be a kernel problem. What I'd suggest is turning on debugging information in pilot-xfer, and running a system-call level trace:

You can get more information from pilot-xfer by
setting the environment variables:
        PILOT_DEBUG="DEV SLP CMP PADP NET SOCK"
        PILOT_DEBUG_LEVEL="DEBUG"
This output might shed some light on the level of the problem.
You could also try 'strace pilot-xfer -p /dev/ttyUSB1 -l'
which will produce a long output.

The output of these two pilot-xfer runs could be attached to this bug report.

Matt,

I ran into the same problems as saniac when trying to run pilot-xfer.

In any case, here's the output from `strace pilot-xfer -p /dev/ttyUSB1 -l`:

*** BOF ***
execve("/usr/bin/pilot-xfer", ["pilot-xfer", "-p", "/dev/ttyUSB1", "-l"], [/* 28 vars */]) = 0
uname({sys="Linux", node="heinsen-dimension-3000", ...}) = 0
brk(0) = 0x804e000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f75000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f73000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=69132, ...}) = 0
old_mmap(NULL, 69132, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f62000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libpisock.so.8", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0J\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=139648, ...}) = 0
old_mmap(NULL, 142712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f3f000
old_mmap(0xb7f5e000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e000) = 0xb7f5e000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \343\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=262860, ...}) = 0
old_mmap(NULL, 264108, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7efe000
old_mmap(0xb7f36000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x38000) = 0xb7f36000
old_mmap(0xb7f3e000, 1964, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f3e000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libreadline.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\272"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=466058, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7efd000
old_mmap(NULL, 187108, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ecf000
old_mmap(0xb7ef8000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x29000) = 0xb7ef8000
old_mmap(0xb7efc000, 2788, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7efc000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220O\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1232784, ...}) = 0
old_mmap(NULL, 1238972, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7da0000
old_mmap(0xb7ec5000, 286...

Thanks, Franz.
The strace output is indeed helpful (although it is a bit frustrating that the
output doesn't appear to be complete - probably stderr hadn't finished
flushing before the process died).

It looks as though pilot-xfer dies in pilot-link's unixserial.c code, in the function
s_open, between lines 199 and 206. My best guess at the moment is that
some recent kernel-related change is the root cause.

I'm not familiar with Ubuntu, but is it possible to downgrade your kernel
package a few revisions and see if the problem disappears? I've also
sent a message to the pilot-link guys to see if it's ringing any bells there.

Matt

Matt, thank you.

Unfortunately, downgrading my kernel is impractical at the moment, as I need continuous access to a handful of kernel-specific compiled applications in this particular PC. However, if I get a chance, I'll look into doing it on another machine (no promises, though).

Franz

Try Upgrading kernel... It seems there may well be some kernel/usbserial bugs in the ubuntu 2.6.15 kernel that is screwing up ttyUSB connections.

See the following Ubuntu bug:
https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/39518

In breezy, kpilot, jpilot worked AOK. I upgraded to dapper & Major sync problems with my Zire 31. Very vary occasional syncs succeed most just hang with no output error and eventually time out. Going back to my breezy install sync works great again. Tries the same with

pilot-xfer -p /dev/ttyUSB1 -l

same as with kpilot & jpilot. So its not the apps, its pilot-xfer or below and there don't seem a lot of dependencies.

Thought I would just chip in - One this one is sorted I am diving into dapper 100% :)

Dave

Here is a full strace of pilot-xfer ....

dave@dave-comp:~$ strace pilot-xfer -p /dev/ttyUSB1 -l
execve("/usr/bin/pilot-xfer", ["pilot-xfer", "-p", "/dev/ttyUSB1", "-l"], [/*
34 vars */]) = 0
uname({sys="Linux", node="dave-comp", ...}) = 0
brk(0) = 0x804e000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f02000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f00000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=96362, ...}) = 0
old_mmap(NULL, 96362, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ee8000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libpisock.so.8", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0J\0\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=139648, ...}) = 0
old_mmap(NULL, 142712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7ec5000
old_mmap(0xb7ee4000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x1e000) = 0xb7ee4000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \343\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=262860, ...}) = 0
old_mmap(NULL, 264108, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e84000
old_mmap(0xb7ebc000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x38000) = 0xb7ebc000
old_mmap(0xb7ec4000, 1964, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7ec4000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/libreadline.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\272"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=466058, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e83000
old_mmap(NULL, 187108, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e55000
old_mmap(0xb7e7e000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x29000) = 0xb7e7e000
old_mmap(0xb7e82000, 2788, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7e82000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220O\1"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1232784, ...}) = 0
old_mmap(NULL, 1238972, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7d26000
old_mmap(0xb7e4b000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_F...

There's not much more to say on this one... it seems very likely that the problem is with the ubuntu 2.6.15 kernel package and has been fixed in more recent revisions. I'd advise building your own kernel, or raising a bug against the kernel package.

Thanks for the info, I will go down the build own kernel route at the weekend.

Cheers

Dave

I see this also with jpilot on an unmodified but updated dapper install - /dev/pilot or /dev/ttyUSB* doesn't appear until you press the button, but jpilot wants the button pressed after you've asked it to do something and it's bound to the port! I also get multiplying /dev/ttyUSB* devices.

I blew up my old Treo a week or two ago and had to restore the backup onto the new one - not being able to do that was a disaster! Fortunately, my housemate's machine wasn't yet upgraded to Dapper and so I was able to copy my jpilot data across and use that. But still, please sort this out ASAP! If I can help with debugging, let me know.

Gerv

Hi Gerv,

I have tried just about everything I can think of, I have upgraded my kernel, compiled the latest version of pilot-link which uses direct libusb support bypassing the visor module, apt-get install --reinstall numerous packages (you never know) and I still only get 1 in 20ish syncs.

I have also tried joining the pilot-link mailing list but there appears to be something wrong with there mail server. I am authenticated and welcomed but cannot send anything to the list.

Googling around it appears a lot of people are having problems. I am using my Wifes breezy machine now to sync my Zire 31. Just glad I stumbled across the problems before I did the big dist-upgrade on hers as well :)

I guess its a case of wait and see, I am sure it will get resolved, hopefully soon.

Dave

The following work-around has solved the problem for me -- i.e. the Treo syncs fine _every time_ when I do the following:

1. Open a terminal and kill the panel applet and the daemon:
$ killall gpilot-applet gpilotd

2. At the command line, type 'gpilotd', but do NOT press <Enter>

3. Connect the Treo to the PC, and click the Treo's sync button

4. When the Treo's screen displays the "Connecting with the desktop..." message, press enter at the command line to run gpilotd

So far, it has worked every time I've tried. Hopefully this information will help solve the bug.

Hi all,

Syncing problems 100% solved :) - Upgraded kernel to 2.6.17.1 and Palm syncing now works perfectly. So it appears that the default kernel is a bit flaky on the USB front

Dave

Any progress on solving this bug?

I'm having this problem too. I was previously running Debian unstable with all the same hardware and syncing worked fine to my USB visor using pilot-link. I reinstalled the laptop with dapper drake and I'm getting the flakiness reported here: once in a blue moon it will work, 95% of the time it hangs immediately while trying to get the user info from the visor. I've tried pilot-link directly and gnome-pilot and experience a similar type of hang with both.

It seems there is some confusion in this thread about pressing the button on the cradle. Even under Debian I had to press the button on the cradle to wake up the device and have it establish the USB connection. There has always been a human-level timing issue when using pilot-link with a USB device: you need to press the button on the cradle first, then start pilot-link before the USB device disconnects. The issue of this bug report appears more like a hang that occurs after pilot-link or gnome-pilot establishes the connection with the device.

I compiled and installed the 2.6.17.6 kernel and though it usually gets further in the syncing now, it still times out. So it's not clear that simply upgrading the kernel solves the problem.

I am sorry you are still having problems, I compiled 2.6.17.1 and now have 100% success.

Because dapper uses UDEV I plug my palm in, start jpilot, hit the sync button on my palm then click the sync button on jpilot. I am no expert but can you post your pilot-link output ?

Dave

I spent about a week in total on this problem, You have upgraded the kernel I assume with 'make oldconfig' after my 'make oldconfig' I had to tweak mine, If you want I will email you my .config, let me know ...

Dave

Robert,

> There has always been a human-level timing
> issue when using pilot-link with a USB device:
> you need to press the button on the cradle
> first, then start pilot-link before the USB device
> disconnects.

Actually, gpilotd and gnome-pilotd did *not* have any human-level timing issues in 5.10 -- they worked fine every single time.

> The issue of this bug report appears more like
> a hang that occurs after pilot-link or gnome-pilot
> establishes the connection with the device.

If you look at the thread, this bug report covers both the occasional hang as well as more frequent time-outs.

Oops, I meant to write "gpilotd," not "gpilotd and gnome-pilotd" in my last post -- sorry for the typo.

Thanks for the helpful responses. My first 2.6.17.6 kernel did have some
config issues which prevented me from seeing the normal boot messages.
I went through almost every option now and think I have something decent.
I also did more experiments with gpilotd and pilot-link.

gpilotd now does a full sync reliably. But only if I start it by manually from
the command line. After the sync is completed, it seems to hang, and
I cannot perform another sync. If I then kill gpilotd and start it again
manually, I can then perform another sync. Perhaps related to this,
/dev/ttyUSB0 and /dev/ttyUSB1 still exist long after my palm device
has disconnected from the bus as long as gpilotd is running. As
soon as I kill gpilotd, those entries disappear. I have setup udev
to create a /dev/pilot symlink to /dev/ttyUSB1. I reconfigured gpilotd
to use /dev/pilot instead of /dev/ttyUSB1 directly and saw the same
behavior.

I also tried using pilot-link. pilot-link will not talk to my
palm device at all. It hangs at the message "please press the hotsync
button now"
when I've already pressed the hotsync button before starting pilot-link.
If I wait until starting pilot-link to press the hotsync button, it complains
that /dev/pilot does not exist. That's the human timing issue I was talking
about. I hadn't ever used gnome-pilot under Debian so I couldn't comment
on anything there.

I also tried jpilot and got a similar result as pilot-link. I pressed
the hotsync
button on the cradle, then pressed a sync button on its GUI and it said "press
the hotsync button". Here are some messages:
J-Pilot: sync PID = 8469
J-Pilot: press the hotsync button on the cradle or "kill 8469"
pi_accept: Connection timed out
pi_accept Illegal seek
Exiting with status SYNC_ERROR_PI_ACCEPT
Finished
J-Pilot: sync PID = 8497
J-Pilot: press the hotsync button on the cradle or "kill 8497"
J-Pilot: sync PID = 8497
J-Pilot: press the hotsync button on the cradle or "kill 8497"
J-Pilot: sync PID = 8497
J-Pilot: press the hotsync button on the cradle or "kill 8497"
J-Pilot: sync PID = 8497
J-Pilot: press the hotsync button on the cradle or "kill 8497"
J-Pilot: sync PID = 8497
J-Pilot: press the hotsync button on the cradle or "kill 8497"
dlp_ReadSysInfo error
Exiting with status SYNC_ERROR_PI_CONNECT
Finished

So at this point I have a usable workaround by running gpilotd manually with
kernel 2.6.17.6. I'm not sure what to make of the fact that palm syncing
app seems to be broken in different ways. Maybe something subtle
has changed in the USB subsystem that is causing them to flake out?

-Rob
--
Robert W. Brewer

After some more playing around, I discovered that the timeout value
of 0 in gpilotd-control-applet was causing gpilot to hang at the end
of the sync. I changed that timeout to 4 seconds and now gpilotd
can perform multiple syncs without having to be killed and restarted.
I had changed it to 0 seconds due to another message somewhere
saying that was a recommended fix for some of these USB sync issues.
I rebooted just to see if that would help with the gpilotd GUIs...
and now it's working! I've done 5 correct syncs in a row via gnome-pilot's
standard GUI interfaces.

So it does appear that moving to the 2.6.17.x kernel is what corrected the
issue for me too.

-Rob
--
Robert W. Brewer

> gpilotd now does a full sync reliably. But only if
> I start it by manually from the command line.

Same here. See https://launchpad.net/distros/ubuntu/+source/gnome-pilot/+bug/38574/comments/30

Glad that the kernel update appears to solve this issue, and that setting a non-zero timeout appears to solve the problem with the ttyUSB devices hanging around after a sync completes. I'm pretty sure this latter issue has been solved in gnome-pilot CVS, and the timeout=0 trick is only required for pilot-link 0.12.0 pre-releases (and maybe Suse's patched 0.11.8 version).

Regards,
Matt

Tonight I tested a full restore of my palm device. First I synced it with
gnome-pilot, which worked correctly from the GUI. Next I cleared
the memory on the device. The restore results
were disappointing. The restore began properly, then the progress
bars started flashing back and forth wildly, then the palm disconnected
and the progress window appeared to be hung. I could not close
the window. I eventually killed gnome-pilot-applet and gpilotd.
I started gpilotd manually without gnome-pilot-applet and the
restore appeared to be going much better. After several
minutes the palm reported that it was complete and prompted me to
reset the device, but gpilotd appeared to be hung still trying to
transfer data. When
I reset the device, it got a fatal exception during bootup. This problem was
no doubt because the restore was only partially completed.

Needless to say it appears this process is still far too flaky to
be my primary means of backing up the device. Once again for reference
this is while running the 2.6.17.6 kernel on an up-to-date dapper drake.

-Rob
--
Robert W. Brewer

A new version (2.0.14) was uploaded to Edgy. It'd be nice if you had a chance to test this and report back, if the problem still persists.

This does now work in Edgy.

However, Dapper is supposed to be supported for five years. People who want a stable Ubuntu also want to be able to sync their Treos. A fix for this problem needs to be backported.

Thanks for following up. If somebody can isolate the fix, we can push it to dapper-updates - the complete changes in pilot-link, gnome-pilot etc are too huge to just push to dapper.

Please open a Dapper task, once a isolated fix is available.

Well, this bug does have "for Dapper Drake" in the title - how much more Dapper-y can you get?

I don't know who the person responsible for this is (whether it's the maintainer of the pilot packages or the kernel team), but saying "Please open a Dapper task, once a isolated fix is available" is basically saying "I hope that a fix for this will magically appear out of the air".

Who is this "somebody" who is going to isolate the fix?

I hope this will be helpful. Modifying the instructions as mentioned earlier for the hard link, I did the following:
as root:
# mknod /dev/m500 c 188 1
# chmod 766 /dev/m500

I was then able to use hotsync easily, since /dev/pilot was otherwise created and deleted over my hard link. The new link doesn't get deleted. I am using debian wheezy, but all other symptoms were practically identical the ones mentioned above.