GNOME Bugzilla – Bug 484509
fails to synchronize when compiled with HAL support
Last modified: 2008-06-26 21:07:19 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.
Created attachment 96846 [details] gpilotd log when compiled with HAL
Created attachment 96847 [details] gpilotd log when compiled without HAL
Created attachment 96848 [details] gdb backtrace when gpilotd is hanging
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?
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.
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.
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.
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
Created attachment 111676 [details] [review] HAL transition patch
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.