After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 484509 - fails to synchronize when compiled with HAL support
fails to synchronize when compiled with HAL support
Status: RESOLVED FIXED
Product: gnome-pilot
Classification: Other
Component: gpilotd
2.0.15
Other Linux
: Normal normal
: ---
Assigned To: gnome-pilot Maintainers
gnome-pilot Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-10-07 20:59 UTC by Arjan Oosting
Modified: 2008-06-26 21:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gpilotd log when compiled with HAL (2.30 KB, text/plain)
2007-10-07 21:01 UTC, Arjan Oosting
  Details
gpilotd log when compiled without HAL (7.63 KB, text/plain)
2007-10-07 21:01 UTC, Arjan Oosting
  Details
gdb backtrace when gpilotd is hanging (1.53 KB, text/plain)
2007-10-07 21:02 UTC, Arjan Oosting
  Details
HAL transition patch (873 bytes, patch)
2008-05-28 17:29 UTC, Bastien Durel
none Details | Review

Description Arjan Oosting 2007-10-07 20:59:34 UTC
Hi,

A couple of Debian users are reporting problems while trying synchronise their Palms through libusb. (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441652. )
They can synchronise once and after that gpilotd fails to synchronise.

I have noticed the same behaviour with my Thungsten E. gpilotd seems to detect that I push the synchronise button, but then seems to hang. Because one of the users can synchronize when he unplugs a (unrelated) usb device I suspected that HAL has something to do with it.

If I recompile gnome-pilot without HAL support (--without-hal) I can indeed synchronise just fine.
 
I am suspecting that a change in HAL caused these problems as it was working before and the version of gnome-pilot in Debian did not change but hal is 
updated from 0.5.8 to 0.5.9 since the release of Debian etch.
Comment 1 Arjan Oosting 2007-10-07 21:01:08 UTC
Created attachment 96846 [details]
gpilotd log when compiled with HAL
Comment 2 Arjan Oosting 2007-10-07 21:01:49 UTC
Created attachment 96847 [details]
gpilotd log when compiled without HAL
Comment 3 Arjan Oosting 2007-10-07 21:02:59 UTC
Created attachment 96848 [details]
gdb backtrace when gpilotd is hanging
Comment 4 Matt Davey 2007-10-08 09:49:24 UTC
Two quick comments:

1. I don't think you will be able to do libusb syncing without HAL.
   Please correct me if I'm wrong.

2. A trick for avoiding recompiling --without-hal is to stop hald
   while you start the gpilotd daemon.  You can then restart hald.

There seem to be a growing number of difficulties with palm syncing recently.
This may be kernel and udev related, or the relative timing between udev
operations and hal notifications.  Not clear yet.  Given that nothing has
changed recently in gnome-pilot it seems that the best we'll be able to do
is to understand the regression and possibly build in some workaround
or increased robustness.

Can you use pilot-xfer at the command line reliably?
Comment 5 queen 2007-10-08 12:15:31 UTC
I'm the bug reporter of this problem in Debian tracking system (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441652). If I kill HAL, I can sync via libusb two or more times. With pilot-xfer can sync too, no matter hald is loaded or not.

When start hald, problem appears again: only sync first time. I have to stop HAL, sync and then restart HAL, or unplug craddle and plug in other USB port to avoid timeout.
Comment 6 Arjan Oosting 2007-10-11 18:55:59 UTC
Hi, 

I don't exactly know which information you need, but let's give it
a go.

> 1. I don't think you will be able to do libusb syncing without HAL.
>   Please correct me if I'm wrong.

libusb syncing without HAL support works just fine. I have compiled gnome-pilot without HAL support and it work fine for me and one of the bug reporters in Debian.

> 2. A trick for avoiding recompiling --without-hal is to stop hald
>   while you start the gpilotd daemon.  You can then restart hald.

Did not try this.

> Can you use pilot-xfer at the command line reliably?

Yes pilot-xfer and jpilot work just fine.
Comment 7 Matt Davey 2007-10-12 08:58:15 UTC
Thanks for the reporting.  I have confirmed the bug and have taken up the issue on the hal mailing list.  This is beginning to look like a bug in hal and/or udev, with a regression (at least for me) between kernel 2.6.21 and 2.6.22.
Comment 8 Bastien Durel 2008-05-28 17:28:17 UTC
As I reported in Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482864 HAL seems to have dropped "info.bus" key in favour of "info.subsystem".

Then as gpilotd tries to read the first one to detect "USBness" of the Palm, it did not regognize it, then discards events.

I'll attach the patch I wrote to synchronize my Palm, works fine for Zire 72 under Lenny
Comment 9 Bastien Durel 2008-05-28 17:29:56 UTC
Created attachment 111676 [details] [review]
HAL transition patch
Comment 10 Matt Davey 2008-06-26 21:07:19 UTC
This should be fixed in svn.  I based the change on a patch submitted to the gnome-pilot-list by Frederic Crozat, and included backwards compatibility with the obsolete syntax for good measure.