GNOME Bugzilla – Bug 321947
gpilotd-WARNING **: Unable to bind to pilot
Last modified: 2006-11-23 16:14:13 UTC
Please describe the problem: I can't get gpilotd to bind to my Treo 650. I'm getting: gpilotd-Message: setting PILOTRATE=9600 (gpilotd:18938): gpilotd-WARNING **: Unable to bind to pilot Steps to reproduce: 1. $ /usr/libexec/gpilotd --oaf-activate-iid=OAFIID:GNOME_Pilot_Daemon 2. Wait a minute. 3. Push the HotSync button on your Treo 650. Actual results: You receive "Unable to bind to pilot" and it does not synchronize. Expected results: It would synchronize. Does this happen every time? Yes. Other information: Here's the full console display: Start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [dalem@BrainIac ~]$ /usr/libexec/gpilotd --oaf-activate-iid=OAFIID:GNOME_Pilot_Daemon gpilotd-Message: gnome-pilot 2.0.13 starting... gpilotd-Message: compiled for pilot-link version 0.12.0-pre4 gpilotd-Message: compiled with [VFS] [USB] [IrDA] [Network] gpilotd-Message: Activating CORBA server IOR:01cde2bf1b00000049444c3a474e4f4d452f50696c6f742f4461656d6f6e3a312e300028030000000054424f600000000101026905000000554e49580066756c18000000427261696e4961632e44616c65486f6d652e6c6f63616c002b0000002f746d702f6f726269742d64616c656d2f6c696e632d343966612d302d36353332303839336434623631004d00000000caaedfba58000000010102312b0000002f746d702f6f726269742d64616c656d2f6c696e632d343966612d302d36353332303839336434623631006c00006f6d1c00000000000000be067490a281e8a8dc292828282828286770696c6f74640001000000480000000136353302000000050000001c00000000000000be067490a281e8a8dc292828282828286770696c6f7464000100000014000000016c696e01000105000000000901010000000000 gpilotd-Message: bonobo_activation_active_server_register = 0 gpilotd-Message: Watching Cradle (/dev/pilot) gpilotd-Message: Found 0830, 0061 gpilotd-Message: Using net TRUE 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: setting PILOTRATE=9600 (gpilotd:18938): gpilotd-WARNING **: Unable to bind to pilot gpilotd-Message: setting PILOTRATE=9600 (gpilotd:18938): gpilotd-WARNING **: Unable to bind to pilot gpilotd-Message: setting PILOTRATE=9600 (gpilotd:18938): gpilotd-WARNING **: Unable to bind to pilot gpilotd-Message: setting PILOTRATE=9600 (gpilotd:18938): gpilotd-WARNING **: Unable to bind to pilot gpilotd-Message: setting PILOTRATE=9600 (gpilotd:18938): gpilotd-WARNING **: Unable to bind to pilot gpilotd-Message: setting PILOTRATE=9600 (gpilotd:18938): gpilotd-WARNING **: pi_accept_to: Socket operation on non-socket (gpilotd:18938): gpilotd-WARNING **: pi_accept_to: timeout was 0 secs gpilotd-Message: setting PILOTRATE=9600 (gpilotd:18938): gpilotd-WARNING **: pi_accept_to: Input/output error (gpilotd:18938): gpilotd-WARNING **: pi_accept_to: timeout was 0 secs gpilotd-Message: Exiting (caught SIGINT)... End - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The SIGINT was my Ctrl-C exit from gpilotd. Here are some pertinant files: [root@BrainIac ~]# cat /usr/share/gnome-pilot/devices.xml <?xml version="1.0" encoding="UTF-8"?> <device-list> <!-- Update this list by adding the hex values for the vendor and product ids under a new "device" node. Set use_net=false *only* if the USB device uses the old PADP protocol over USB, this should not apply to any new devices and only applies to the Handspring visor as far as i know --> <!-- Treo --> <!-- Treo 650 --> <device vendor_id="0830" product_id="0061" /> <!-- Aceeca --> <!-- Aceeca MEZ1000 --> <device vendor_id="4766" product_id="0001"/> <!-- Acer --> <!-- Acer S50/S60 --> <device vendor_id="0502" product_id="0736"/> <!-- Garmin --> <!-- Garmin Ique 3600 --> <device vendor_id="091e" product_id="0004"/> <!-- Handspring --> <!-- Handspring Visor and Treo 300 --> <device vendor_id="082d" product_id="0100" use_net="false"/> <!-- Handspring Treo --> <device vendor_id="082d" product_id="0200" /> <!-- Handspring Treo 600 --> <device vendor_id="082d" product_id="0300" /> <!-- Kyocera --> <!-- Kyocera 7135 --> <device vendor_id="0c88" product_id="0021"/> <!-- Palm --> <!-- Palm M500 --> <device vendor_id="0830" product_id="0001" /> <!-- Palm M505 --> <device vendor_id="0830" product_id="0002" /> <!-- Palm M515 --> <device vendor_id="0830" product_id="0003" /> <!-- Palm I705 --> <device vendor_id="0830" product_id="0020" /> <!-- Palm Tungsten Z --> <device vendor_id="0830" product_id="0031" /> <!-- Palm M125 --> <device vendor_id="0830" product_id="0040" /> <!-- Palm M130 --> <device vendor_id="0830" product_id="0050" /> <!-- Palm Tungsten T --> <device vendor_id="0830" product_id="0060" /> <!-- Palm Zire 31 --> <device vendor_id="0830" product_id="0061" /> <!-- Palm Zire --> <device vendor_id="0830" product_id="0070" /> <!-- Palm M100 --> <device vendor_id="0830" product_id="0080" /> <!-- Samsung --> <!-- Samsung SCH-I330 --> <device vendor_id="04e8" product_id="8001" /> <!-- Samsung SPH-I500 --> <device vendor_id="04e8" product_id="6601" /> <!-- Sony --> <!-- Sony Clie 3.5 --> <device vendor_id="054c" product_id="0038" /> <!-- Sony Clie 4.0 --> <device vendor_id="054c" product_id="0066" /> <!-- Sony Clie S360 --> <device vendor_id="054c" product_id="0095" /> <!-- Sony Clie 4.1 --> <device vendor_id="054c" product_id="009a" /> <!-- Sony Clie NZ90V --> <device vendor_id="054c" product_id="00c9" /> <!-- Sony Clie NX60 --> <device vendor_id="054c" product_id="00da" /> <!-- Sony Clie NZ90V --> <device vendor_id="054c" product_id="00e9" /> <!-- Sony Clie UX50 --> <device vendor_id="054c" product_id="0144" /> <!-- Sony Clie TJ25 --> <device vendor_id="054c" product_id="0169" /> <!-- Tapwave --> <!-- Tapwave Zodiac --> <device vendor_id="12ef" product_id="0100" /> </device-list> [root@BrainIac ~]# cat /etc/udev/permissions.d/10-visor.permissions ttyUSB1:$local:uucp:0660 [root@BrainIac ~]# cat /etc/udev/rules.d/10-visor.rules BUS="usb", KERNEL="ttyUSB[13579]", SYMLINK="pilot", MODE="660" #BUS="usb", SYSFS{product}="Handspring*", KERNEL="ttyUSB[13579]", SYMLINK="pilot", MODE="660" #BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB[13579]", SYMLINK="pilot", MODE="660" #BUS="usb", SYSFS{product}="PalmSN12345678", KERNEL="ttyUSB*", SYMLINK="pilot" #BUS="usb", SYSFS{product}="palmOne Handheld*", KERNEL="ttyUSB*", SYMLINK="pilot" [dalem@BrainIac ~]$ /usr/libexec/gpilotd --version gpilotd-Message: gnome-pilot 2.0.13 starting... gpilotd-Message: compiled for pilot-link version 0.12.0-pre4 gpilotd-Message: compiled with [VFS] [USB] [IrDA] [Network] Gnome gnome-pilot 2.0.13
[dalem@BrainIac ~]$ rpm -qa | grep pilot pilot-link-0.12.0-0.pre4.0.fc4.2 gnome-pilot-2.0.13-4 gnome-pilot-conduits-2.0.13-2 jpilot-0.99.8-0.pre10.fc4.1 [dalem@BrainIac ~]$ uname -a Linux BrainIac.DaleHome.local 2.6.12-1.1456_FC4 #1 Thu Sep 22 02:11:40 EDT 2005 i686 i686 i386 GNU/Linux
Is /dev/pilot the right device? Have you tried ttyUSB0? Have you checked that it is getting created with the right permissions? To rule out these problems, you can try running "pilot-xfer -p /dev/pilot" or "pilot-xfer -p /dev/ttyUSB0" for example.
This looks like it could be the 'slow udev' issue, too.
Hello? If you can still reproduce this bug, please try the pilot-xfer test as suggested in comment 2 and let us know what happens.
I'm seeing the same behavior... Trying to config gnome-pilot for the first time (just installed Suse 10.1 - I have found a comment in a google search which indicates this worked in Suse 10.0) The Pilot Tungsten C has been synced before. I run the gpilot-control applet. The vendor id and product id are indeed in devices,xml. I have tried pressing the sync button before proceeding past the config dialog where I set /dev/pilot, 115kbps, timeout of 60000 (apparently according to a google post this is supposed to be seconds but is currently interpreted as ms. Pilot-xfer and kpilot work fine. I'm running the following rpms: (I also did a Suse online update but nothing related appeared) rpm -qa |grep -i gnome-pilot gnome-pilot-conduits-2.0.13-21 gnome-pilot-devel-2.0.13-43 gnome-pilot-2.0.13-43 What is the "slow udev" issue mentioned above in comment #3 Could you please link to the bug report on this item. Is there a workaround? Should I try the latest from cvs perhaps?
A few answers and questions... Do you have the file /proc/bus/usb/devices? gnome-pilot relies on it. If it doesn't exist, try doing 'mount -t usbfs /proc/bus/usb /proc/bus/usb' (as root). (/proc/bus/usb has apparently been deprecated since the release of gp 2.0.13. The next release of gnome-pilot will not require it, but for now it's essential). By all means, do try compiling gnome-pilot from CVS. There is a pretty recent unofficial tarball available from http://www.inference.phy.cam.ac.uk/mcdavey/downloads/ which you might like to try out. The 'slow udev' issue refers to certain kernel/udev revisions, where there appears to be quite a long delay between the palm sync starting and the device files getting created. This can mean that by the time gnome-pilot realises there's a sync attempt the palm has given up. I don't know if this is your problem.
Wow! Thanks for the fast reply...A few answers to your questions... I do have /proc/bus/usb and /etc/fstab has been configured to mount as you describe. I grabbed the tar file for gnome-pilot 2.0.14 pre-release from the site you mentioned. I built and installed it with a prefix of /opt/test-gnome-pilot, then adjusted my path to look in it's bin and libexec dirs and my ld library path to look in it's lib dir. I started the gpilot-control-applet. Next I answered it's questions - left things pretty much as it suggested - changed the delay to 60000 and changed type of connection to USB. I tried pressing the hotsync button at that screen then proceeding through the next two (which has worked for some). I also tried waiting till I got to the the screen that directed me to do so. I also tried these two methods with delay set to 0 (no timeout is what I'm guessing this means) - as the a README or INSTALL file in the tar file mentioned. None of these methods improved things any - watching /var/log/messages and usbview I can see the palm is being recognized and eventually disconnects when the timeout expires - yet the Forward button never ungrays. The web link above also mentions bugs in version 0.12 prerelease of pilot-link - I am using pilot-link 0.11-8-139 - so I decided to try without the latest version of this rpm from CVS - now I'm thinking maybe I should try that as well. Any other ideas?
If you have /proc/bus/usb/devices, and pilot-xfer is working reliably, then it is likely that you can get gnome-pilot working. The next step is to run gpilotd in a terminal window and watch the output. This will tell you if gnome-pilot is attempting to sync or not. So do: killall gpilotd /opt/test-gnome-pilot/libexec/gpilotd Now run the applet and send us in the output from your terminal window.
Ok, I have now done as suggested... I played around a bit before doing the suggested steps with logging turned on...at one point I heard the normal start/stop sync tones...then the next time I ran the contol panel I saw that I have somehow I managed to get things into a state where the panel shows rather than displaying the wizard for configuration - but when I try to have it fetch my id from the pilot using this control panel, it complains: gpilotd-WARNING **: An error occurred while getting the PDA's system data I have attached the output of both my terminal window of gpilotd-control-panel (gpilotd-control-panel.log) and that of gpilotd (gpilot.log) itself. Can I get gpilotd to give you a higher level of debug output somehow? This whole process is made more difficult by the finickyness of the cradle - I find it hard to get the pilot seated correctly and to have it stay that way - that's why I watch usbview - to make sure the usb bus is seeing it once the sync button is pressed.
Created attachment 68044 [details] gpilotd.log
Created attachment 68045 [details] gpilotd-panel log
yes, more info would be good... you can get some additional debug info by setting the following pilot-link environment variables in the terminal before starting gpilotd: PILOT_DEBUG="DEV SLP CMP PADP NET SOCK" PILOT_DEBUG_LEVEL="DEBUG" What kernel version are you using?
Ok, tried a few more things - tested with a second palm pilot of same type - behaves same way (can get listings using pilot-xfer -l, can't sync using gpilotd - did not test the second pilot using kpilot, but the first works fine) I also logged in as root to avoid any permission errors (I noticed /dev/ttyUSB3 was being created with uucp group and perms that did not allow me a user to access - think it was owned by root - so I added myself to the uucp group) Still no change. What follows below has been cut and paste from turning on more debugging - it contains gpilotd and gpilotd-control-panel output. My next plan is to try a newer version of pilot-link???? What do you suggest? I'm still using the shipped one - 0.11.x gpilotd & [5] 28052 [4] Terminated gpilotd-control-applet networkxxiii:~ # gpilotd-Message: gnome-pilot 2.0.14pre5 starting... gpilotd-Message: compiled for pilot-link version 0.11.8 gpilotd-Message: compiled with [VFS] [USB] [IrDA] [Network] gpilotd-Message: Removed stale lock on /dev/pilot (pid 27489) (gpilotd:28052): gpilotd-WARNING **: Number of PDAs is configured to 0 gpilotd-Message: Activating CORBA server gpilotd-Message: bonobo_activation_active_server_register = 0 gpilotd-Message: Watching Cradle (/dev/pilot) networkxxiii:~ # gpilotd-control-applet ** Message: No pilot userid/username information located ** Message: Unable to load pilot id/username, assuming unset ** Message: Cradle Type -> USB ** Message: cradle device name -> Cradle ** Message: cradle device name -> /dev/pilot ** Message: Pilot Speed -> 57600 ** Message: Timeout -> 100 gpilotd-Message: Activating object OAFIID:GNOME_Pilot_Daemon ** Message: No pilot userid/username information located ** Message: Unable to load pilot id/username, assuming unset ** Message: Cradle Type -> USB ** Message: cradle device name -> Cradle ** Message: cradle device name -> /dev/pilot ** Message: Pilot Speed -> 57600 ** Message: Timeout -> 100 gpilotd-Message: Shutting down devices gpilotd-Message: Rereading configuration... (gpilotd:28052): gpilotd-WARNING **: Number of PDAs is configured to 0 gpilotd-Message: Watching Cradle (/dev/pilot) gpilotd-Message: corba: get_user_info(cradle=Cradle,survival=0,timeout=0) gpilotd-Message: assigned handle num 6 gpilotd-Message: corba: get_system_info(cradle=Cradle,survival=0,timeout=0) gpilotd-Message: assigned handle num 7 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: setting PILOTRATE=57600 DEV POLL Serial Unix Found data on fd: 20 serial.c: 398, poll result: 0. DEV TX Unix Serial Bytes: 6 DEV POLL Serial Unix Found data on fd: 20 DEV RX Unix Serial Bytes: 1 NET RX: Checking for headerless packet 1 DEV RX Unix Serial Bytes: 5 DEV RX Unix Serial Bytes: 22 NET RX type=1 txid=0xff len=0x0016 0000 90 01 00 00 00 00 00 00 00 20 00 00 00 08 00 00 ......... ...... 0010 01 00 00 00 00 00 ...... DEV TX Unix Serial Bytes: 6 DEV TX Unix Serial Bytes: 50 NET TX type=1 txid=0xff len=0x0032 0000 12 01 00 00 00 00 00 00 00 20 00 00 00 24 ff ff ......... ...$.. 0010 ff ff 3c 00 3c 00 00 00 00 00 00 00 00 00 c0 a8 ..<.<........... 0020 a5 1f 04 27 00 00 00 00 00 00 00 00 00 00 00 00 ...'............ 0030 00 00 .. DEV RX Unix Serial Bytes: 6 DEV RX Unix Serial Bytes: 8 NET RX type=1 txid=0x00 len=0x0008 0000 90 00 00 02 00 00 00 00 ........ DEV TX Unix Serial Bytes: 6 DEV TX Unix Serial Bytes: 46 NET TX type=1 txid=0x00 len=0x002e 0000 13 01 00 00 00 00 00 00 00 20 00 00 00 20 ff ff ......... ... .. 0010 ff ff 00 3c 00 3c 00 00 00 00 00 00 00 01 00 00 ...<.<.......... 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .............. DEV RX Unix Serial Bytes: 1 NET RX: Checking for headerless packet 1 DEV RX Unix Serial Bytes: 5 DEV RX Unix Serial Bytes: 50 NET RX type=1 txid=0xff len=0x0032 0000 92 01 00 00 00 00 00 00 00 20 00 00 00 24 ff ff ......... ...$.. 0010 ff ff 00 3c 00 3c 40 00 00 00 01 00 00 00 00 00 ...<.<@......... 0020 04 00 00 00 04 00 00 3c 00 3c 00 00 00 00 20 62 .......<.<.... b 0030 cf 00 .. DEV CLOSE Serial Unix fd: 20 DEV TX Unix Serial Bytes: 6 DEV TX Unix Serial Bytes: 8 NET TX type=1 txid=0x00 len=0x0008 0000 12 01 20 04 00 01 00 03 .. ..... DEV RX Unix Serial Bytes: 1 NET RX: Checking for headerless packet 1 DEV RX Unix Serial Bytes: 5 DEV RX Unix Serial Bytes: 8 NET RX type=1 txid=0x00 len=0x0008 0000 93 00 00 00 00 00 00 00 ........ (gpilotd:28052): gpilotd-WARNING **: An error occurred while getting the PDA's s ystem data DEV TX Unix Serial Bytes: 6 DEV TX Unix Serial Bytes: 6 NET TX type=1 txid=0x01 len=0x0006 0000 2f 01 20 02 00 00 /. ... DEV RX Unix Serial Bytes: 6 DEV RX Unix Serial Bytes: 34 NET RX type=1 txid=0x00 len=0x0022 0000 92 02 00 00 20 0e 05 21 30 00 00 01 00 00 00 04 .... ..!0....... 0010 00 16 00 00 21 0c 00 01 00 02 00 03 00 00 00 00 ....!........... 0020 ff e1 .. DEV TX Unix Serial Bytes: 6 DEV TX Unix Serial Bytes: 6 NET TX type=1 txid=0xff len=0x0006 0000 2f 01 20 02 00 00 /. ... DEV RX Unix Serial Bytes: 6 DEV RX Unix Serial Bytes: 4 NET RX type=1 txid=0x01 len=0x0004 0000 af 00 00 00 .... DEV CLOSE Serial Unix fd: 21 ------------------------------------------------ end debug info --------- Not sure how much this helps - one more note - the pilot shows show garbage characters on the upper right corner of the hotsync display after doing this sync - almost like there was a speed or parity matching problem???? Any ideas????
Trace I just posted is from a test on the second pda - that one apparently has no owner set so there are garbage characters displayed in the upper right corner - where owner or actually pilot name is displayed
Hi again. Thanks very much for the debug output. Very helpful, but it's a bit surprising, too. Even though gnome-pilot states it was compiled for pilot-link 0.11.8, your output revealed that SUSE are using some patches from the pilot-link 0.12.0 development. I suspect that one of these patches appears to be causing the problem for you. (for the record, it's the code in bug: http://bugs.pilot-link.org/1585). The first thing to try is to set the 'timeout' device parameter for gnome-pilot from 2 to 0. This option is on the screen where you select '/dev/pilot', or '/dev/ttyUSB0', etc. If you're lucky, that might even solve your problem. Matt p.s. Note to other readers: this timeout of zero is not recommended in general, as it can cause gpilotd to appear to 'hang', requiring you to kill the gpilotd process. It is a specific workaround for the pilot-link behaviour described in http://bugs.pilot-link.org/1585.
Hi Matt, I try to sync a Palm Tungsten C on connected via usb. my gpilotd log: (I open unconfigured gpilotd-control-applet to receive username and id from the pilot) gpilotd-Message: corba: get_user_info(cradle=Cradle,survival=0,timeout=0) gpilotd-Message: assigned handle num 12 gpilotd-Message: palm pda detected by HAL gpilotd-Message: setting PILOTRATE=57600 DEV POLL Serial Unix Found data on fd: 18 DEV RX Unix Serial Bytes: 3 SLP RX Unexpected signature 0x01 0xff 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0xff 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x16 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x16 0x90 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x16 0x90 0x01 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x90 0x01 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x01 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x20 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x20 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x20 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x08 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x08 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x08 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x01 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x01 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x01 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 DEV RX Unix Serial Bytes: 1 SLP RX Unexpected signature 0x00 0x00 0x00 ... if you need further information please tell me. Regards Michael http://www.ciit.at
Thanks for the update. After digging into this a bit more, I discover that SUSE have applied some experimental HAL patches to gnome-pilot. These patches have been superceded in CVS, and actually contain a bug that I suspect is the cause of your woes. How do you feel about rebuilding an RPM from source? If you unpack the gnome-pilot-2.0.13-43.src.rpm and find the "gnome-pilot-hal.patch" file, then go to line 921 and change "visor_net = FALSE;" to "visor_net = TRUE;" and on line 951 change "visor_net = TRUE;" to "visor_net = FALSE;" Alternatively, you could try building gnome-pilot from source, as mentioned in comment #6 on this bug.
The SUSE HAL patch has been updated to fix this problem and should be available in SUSE factory. Try upgrading to the suse factory package gnome-pilot-2.0.13-45.src.rpm. See also: https://bugzilla.novell.com/show_bug.cgi?id=165455 I'm closing this bug, but feel free to reopen if you continue to experience problems after installing the above package.
*** Bug 368824 has been marked as a duplicate of this bug. ***
The above package doesn't solve the problem reported in bug.
It isn't a problem with choosing the wrong ttyUSB device, is it? Did you try both ttyUSB0 and ttyUSB1? (or, whichever one works with pilot-xfer).
I'm using /dev/ttyUSB1, which works just fine with pilot-xfer and worked fine under SUSE 9.3.
I hava a similar problem syncing with my Palm TX. I'm using Ubuntu Edgy (gnome-pilot 2.0.14) gpilotd's output is very similar to the one that already is here. Somehow, gpilotd resets (soft reset) my palm if it is running, while it displays this message: gpilotd-Message: setting PILOTRATE=57600 I have tested the pilot-xfer command with the following line: pilot-xfer -p /dev/pilot -l which confirmed that /dev/pilot is the right device (it only appears when I connect the palm and points to the recently created /dev/ttyUSB# ), under the following circunstances: If I run this command, it simply doesn't work. For it to work I have to first press the hotsync button in the palm, wait one or two seconds and then run it. If using gpilot-applet or gpilotd, besides resetting the palm, it starts consuming 100% CPU, a lot of RAM and the PC's load skyrockets.
Additionally, I've tried syncing with jpilot. It displays the same problem as with pilot-xfer... I have to press the hotsync button first, then the button in the app, otherwise it goes 100% CPU. It looks like a general palm problem. I have also tried a simple cat /dev/pilot I ran the command, and just as I pressed the hotsync button, the command exitted, like if it received and EOF. The sync screen didn't go out in the palm, so I ran the cat command again, and it started outputting stuff (binary, most likely what it should output normally)
Ronan, Your issue is almost certainly bug 362565: http://bugzilla.gnome.org/show_bug.cgi?id=362565 Jon: What pilot-link package do you have installed? If it is based on pilot-link 0.12.x then your issue may be similar to #362565.
I'm using pilot-link 0.11.8-139
Jon, did you get a chance to try the patched gnome-pilot tarball mentioned in comment 7 in bug 362565? From your comment #4 on bug 368824 I presume it was the suse source rpm you had trouble compiling. I'd be interested to hear any success/failure report for the patched tarball.
I have been unsuccessful in building gnome-pilot on my system. I have tried the updated gnome-pilot listed in this bug at Novell: https://bugzilla.novell.com/show_bug.cgi?id=165455
Have a try with the tarball distribution. I don't _think_ you'll hit the same problem. You can compile and run gnome-pilot from a temporary location so that you can test it without overwriting your system installation: 1. download and unpack tarball. 2. cd into directory and do './configure --prefix=/tmp/gp' 3. make; make install then kill any running gpilotd and run from /tmp/gp/libexec/gpilotd
Nope, that didn't work either. I did the following: 1. start /tmp/gp/libexec/gpilotd 2. Goto synchronization settings on Evolution (this connected to my gpilotd output) 3. Told the synchronization dialog that I wanted to get the ID off of my palm 4. Pressed the hotsync button when asked At this point my palm made noises that it connected (which I've been able to get to work so far) and then disconnected and no id is retrieved. >/tmp/gp/libexec/gpilotd gpilotd-Message: gnome-pilot 2.0.14 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 Treo650 (/dev/ttyUSB1) gpilotd-Message: Client seems ok gpilotd-Message: Client seems ok gpilotd-Message: monitor_on(pilot_name="MyPilot",client_id = IOR:010cbd701b000000...) gpilotd-Message: corba: notify_on(event_type=CONNECT,callback=IOR:010cbd701b000000...) gpilotd-Message: corba: notify_on(event_type=DISCONNECT,callback=IOR:010cbd701b000000...) gpilotd-Message: corba: get_user_info(cradle=Treo650,survival=0,timeout=0) gpilotd-Message: assigned handle num 2 gpilotd-Message: corba: get_system_info(cradle=Treo650,survival=0,timeout=0) gpilotd-Message: assigned handle num 3 gpilotd-Message: Found 4766, 0001 gpilotd-Message: Using net TRUE gpilotd-Message: Found 0502, 0736 ... (lost more of these messages) pilotd-Message: Using net TRUE gpilotd-Message: Found 12ef, 0100 gpilotd-Message: Using net TRUE gpilotd-Message: setting PILOTRATE=115200 (gpilotd:30797): gpilotd-WARNING **: An error occurred while getting the PDA's system data gpilotd-Message: FISK: OST gpilotd-Message: gpc_queue_purge_request() gpilotd-Message: FISK: OST gpilotd-Message: gpc_queue_purge_request() gpilotd-Message: Exiting (caught SIGINT)... The signal was me killing gpilotd with ctrl-c after it failed to work.
Jon, that's good news that you got the tarball to build. try playing with the 'timeout' setting in the device configuration for your 'Treo650' device. In the patched version you're running, the timeout is also used to introduce a short delay between detecting the device and initiating a sync. Values in the range 2 to 10 may make a difference. Another thing worth trying is pilot-link 0.12.1. 0.11.8 predates the Treo650 by a couple of years, and although it is working well with pilot-xfer, gnome-pilot uses pilot-link in a way that can introduce timing issues with device creation. You can download a tarball from pilot-link.org, and install with the same configure/make steps you used for gnome-pilot. Then you'll need to recompile gnome-pilot using: ./configure --prefix=/tmp/gp --with-pisock=/tmp/gp to tell it to use the 0.12.1 headers. These bugs are frustrating for you, but for the developers too. I can't reproduce this bug, or the other bug affecting Ubuntu users of gp 2.0.14, making it rather laborious tracking down and fixing the bugs :( Thanks for your help.
You've been most helpful, thank you. It worked! Now, would anyone happen to have these packages as x86_64 RPMs already built that I can install, so I can use the condiuts on my system?
What, exactly, worked? i.e. did you need to compile against pilot-link 0.12.1? did you need to fiddle with the timeout settings, and if so what value(s) do you find work reliably? AFAIK, there are no SUSE packages based on this test tarball, and I don't expect there will be. These changes are going to get rolled up in a 2.0.15 release. There's at least one more bug I'm chasing down. Sorry I can't help more on the packaging side - I guess you could update your suse ticket and look for help.
I built the patched gnome-pilot with pilot-link 0.12. At this point I was able to send and receive the username and sync id on my Palm from Evolution. I'm unable to get the evolution conduits to work as they're not found. I tried copying the conduits directory over from my system install, but that didn't help. Though I am able to use the backup conduit.
Jon: did you copy across the ".conduit" files, too? They're usually put under /usr/share/gnome-pilot/conduits, but locations can vary. I'm going to mark this as fixed, as it seems that the recent patch, as released in 2.0.15, allows syncing. (to /dev/pilot users: ensure that /dev/pilot is pointing to the right /dev/ttyUSBx device, or use the correct /dev/ttyUSBx device directly). Feel free to update this ticket with success/failure stories on this issue with 2.0.15.
I copied the .conduit files over and then turned on the backup conduit (which worked for me previously) and the e-address conduit using the control applet from my running evolution. The backup went just fine, but when it got to the e-address conduit I got a seg fault. My guess is this has something to do with the pilot-link api changing, so I'll probably have to wait until I can get all of the conduits rebuilt, unless someone has an easy way to do that without rebuilding my whole system? eaddrconduit-Message: --------------------------------------------------------- eaddrconduit-Message: pre_sync: Addressbook Conduit v.0.1.2 [New Thread 1082132800 (LWP 4579)] [New Thread 1082399040 (LWP 4580)] Program received signal SIGSEGV, Segmentation fault.
+ Trace 88774
Thread 47924178634672 (LWP 4552)
Yes, you've got your evolution conduit linked against pilot-link 0.11.8, and gpilotd compiled against 0.12.1, which won't work. Your simplest option, if it works for you, is to recompile gnome-pilot with pilot-link 0.11.8. You could even try the official gnome-pilot 2.0.15 from: http://download.gnome.org/sources/gnome-pilot/2.0/gnome-pilot-2.0.15.tar.gz Although things started working for you when you upgraded to 0.12.1, the change to the newer gnome-pilot may have been sufficient. Worth a try, anyway. The other option is to patch the evolution conduits and rebuild evolution against pilot-link 0.12.1. That's definitely a bigger job.
No, just the newer gnome-pilot doesn't work, see comment 30. As far as rebuilding it all, I looked into it and I don't really want to tackle that now. SUSE 10.2 is supposed to have the new pilot-link and that's due the middle of december, so I think I'll just wait.
Bummer. I was hoping that playing with the timeout settings in the new gp would be suffcient. Hope it's not a long wait for 10.2, in that case! /Matt
Where exactly did you change the timeouts in the code? I didn't try messing around with them, but still can.
I changed the timeout to 0 in the sync options dialog and it started the backup and then died with a seg fault. So it looks like there is something still wrong. backupconduit-Message: Moving backup from /home/jpschewe/treo650/evolution/0/ContactsDB-PAdd.pdb to /home/jpschewe/treo650/evolution/1/ContactsDB-PAdd.pdb Program received signal SIGSEGV, Segmentation fault.
+ Trace 88801
Thread 47445318272128 (LWP 26831)
I got it. I copied the backup.conduit file from my system install into the new install directory and that fixed the crash. So what I did was compile the new gnome-pilot against pilot-link 0.11 and then set the timeout in the options dialog to 0. Then I copied all of the *.conduit files from the system install into my temporary install directory. Now I've successfully run a backup and the e-address conduit.
That's great news. By the way, the crash in comment 41 implies that the backup_conduit hadn't been properly recompiled against pilot-link 0.11.8 (the stack trace shows "backup_conduit.c:492", a line that should be ifdef'd out in the 0.11.8 case. So, probably there's a buglet in the makefile dependency checking that didn't pick up the change in config.h. Anyway, very glad to hear it's working for you now :)