Bug 449968 - pilot-link fails to communicate with Palm m130 using libusb
pilot-link fails to communicate with Palm m130 using libusb
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: pilot-link (Show other bugs)
15
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Schiffer
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-04 11:06 EDT by Adam Stein
Modified: 2012-06-01 12:55 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-01 12:55:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Debug information from pilot-xfer (35.44 KB, text/plain)
2008-06-04 11:08 EDT, Adam Stein
no flags Details

  None (edit)
Description Adam Stein 2008-06-04 11:06:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

Description of problem:
I have a Palm m130 that was synching fine (using Evolution or pilot-link
tools) on a Fedora Core 4 32-bit system.

My system is now upgraded to Fedora 8 on a 64-bit system.  Instead of
using visor, I'm trying to connect using libusb (i.e. the new correct
way).

The problem is that the system doesn't see the device.  Tried running:

	sudo pilot-xfer -p usb: -l

Running pilot-xfer as root to avoid any additional permission problems.  All pilot-xfer does is display it's 'Listening for incoming connection on usb:...' message and sit there.

This is clearly a communication problem given what I tried and what I know works (see Additional info).

Version-Release number of selected component (if applicable):
pilot-link-0.12.3

How reproducible:
Always


Steps to Reproduce:
1. Put Palm m130 into cradle
2. Run 'sudo pilot-xfer -p usb: -l'
3. Press cradle hotsync button
4. Become frustrated as pilot-xfer never connects

Switching steps 2 and 3 (press hotsync FIRST, then run command) produces the same results.

Actual Results:
pilot-xfer prints it's listening message and just sits there.  Eventually, the Palm m130 hotsync times out.

Expected Results:
Given the 'pilot-xfer -p usb: -l' command, I expected to see a list of database files on the Palm m130.

Additional info:
Always run pilot-xfer as root to avoid permission problems.

I've followed all the directions I could find (doc/README.libusb and various mailing lists posts).  Visor is blacklisted, running lsusb shows the Palm device, entries are being made in /dev/bus/usb.

Verified that the pilot rules (doc/60-libpisock.rules) are being used after copying it to /etc/udev/rules.d, changing the GROUP from 'dialout' to 'uucp', and reloading the rules (udevcontrol --reload_rules).  No errors from udev about reading the rules file.

I've tried compiling pilot-link myself when the yum installed version
didn't work (verifying that libusb was enabled).  Tried the version in CVS (as of June 2, 2008).  Tried the Koji version (http://koji.fedoraproject.org/koji/taskinfo?taskID=632388).

Tried the patch for z22 (http://mail.gnome.org/archives/gnome-pilot-list/2007-October/msg00011.html).  Tried the other patch for z22 (http://lists.pilot-link.org/pipermail/pilot-link-general/2007-November/003271.html) except that I tried the flag for the m130 entry.  Tried the USB_INIT_NONE flag.

My initial post on the pilot-link mailing list can be found at http://lists.pilot-link.org/pipermail/pilot-link-general/2008-May/003351.html and the discussion continues in June at http://lists.pilot-link.org/pipermail/pilot-link-general/2008-June/003374.html.
Comment 1 Adam Stein 2008-06-04 11:08:28 EDT
Created attachment 308354 [details]
Debug information from pilot-xfer

This debug log was created using the following settings:

    setenv PILOT_DEBUG "DEV SLP CMP NET SOCK USER"
    setenv PILOT_DEBUG_LEVEL "DEBUG"
    setenv PILOT_LOGFILE "pilot-link-debug.log"
    setenv PILOT_LOG 1
Comment 2 Kevin R. Page 2008-06-04 11:27:48 EDT
Just to note that I've tried to step through this issue with Adam on the
pilot-link-general mailing list (see the links he provides), and as far as I can
tell this is NOT a problem with permissions - he's tried testing as root, and
using the F8 test RPM for PolicyKit from bug #280251.

Instead, it would appear to be a genuine incompatibility problem between the
pilot-link libusb code and m130 handhelds.

The upstream developer hopes to buy some m130 hardware to work on this issue.
Comment 3 Ivana Varekova 2008-06-23 04:58:05 EDT
Because of the previous comment I think the current upstream cvs version is not
fixed, but could you please test that version - I did not found any notice about
the result of this test on http://lists.pilot-link.org discussions. 
Thanks.
Comment 4 Kevin R. Page 2008-06-23 05:15:21 EDT
I believe we are waiting for a pilot-link developer to buy, or be donated, M130
hardware to test with. It's not for sale in retail any more, so this could take
a while. Discussion on the pilot-link list stalled at that point.

This incompatibility keeps cropping up in forums, so I think this bug should be
left open, although the solution is likely to come from upstream.
Comment 5 Ivana Varekova 2008-06-23 05:42:30 EDT
I think it would be nice if the bug reporter try to test the cvs version - there
is no notice about any test and there is a chance the upstream cvs fix it. But
if there is no change then I agree with you, the best solution is to wait.
Comment 6 Kevin R. Page 2008-06-23 05:57:25 EDT
Ivana: the thread continues in the June archive of the mailing list; the
reporter has tested the CVS version:
http://lists.pilot-link.org/pipermail/pilot-link-general/2008-June/003374.html

Adam: and you had no luck with the F9 liveCD either? (Just to confirm the bug is
common to F8 and F9)
Comment 7 Ivana Varekova 2008-06-23 08:20:01 EDT
Ops. I don't understand this comment properly - when I read it, you are right,
thanks.
Comment 8 Adam Stein 2008-06-24 08:22:39 EDT
As stated, I did try the CVS version (as of June 2) with no luck.  I never
bothered with the Fedora 9 liveCD since I think Kevin mentioned that it probably
wouldn't work.

On a side note, I did get syncing working with the old Visor module for the time
being.

I'm in the middle of recovering from a hard disk failure (found out the day
before the drive crashed that my system wasn't being backed up anymore because
of an IP # change -- fine time to tell me!)

If people think that I should try the Fedora 9 liveCD, I can.  It might take a
while as I try to get back to where I was and catch up on all my missed work :-{(
Comment 9 Brian Mury 2008-06-24 19:13:45 EDT
I haven't tried the live CD, but I am running a regular F9 installation and
libusb does not work with my m130 - behaviour is the same as the original bug
report.
Comment 10 Ivana Varekova 2008-06-25 03:05:04 EDT
Adam, Brian thanks a lot for your help - in fc there is no patch which could fix
it. I agree with Kevin - the best solution for now it to wait for upstream.
Comment 11 Alex Butcher 2008-08-02 06:47:10 EDT
On a fully-patched FC8, I symlinked /etc/udev/rules.d/60-libpisock.rules and
60-pilot.rules to the respective .rules.fedora files in
/usr/share/pilot-link/udev/. /dev/ttyUSB? and /dev/pilot files were created
(/dev/pilot as a symlink to /dev/ttyUSB1), but pilot-link couldn't connect to
/dev/pilot and my M130 eventually timed out.

However, if I told pilot-link to connect to /dev/ttyUSB0, i.e.

pilot-xfer -p /dev/ttyUSB0 -l

then all was well. I propose therefore, that 60-pilot.rules ought to link to
contain:

BUS=="usb", SYSFS{product}=="Palm
Handheld*|Handspring*",KERNEL=="ttyUSB[02468]", SYMLINK="pilot", GROUP="uucp",
MODE="0660"

pilot-link is 0.12.2-21.fc8, kernel is 2.6.25.11-60.fc8, udev is 118-1.fc8, hal
is 0.5.10-3.fc8
Comment 12 Kevin R. Page 2008-08-02 22:44:08 EDT
Alex: libusb - which doesn't require use of the udev rules - is now the default for pilot-link in Fedora, but as this bug shows there are still a few devices not yet compatible with the libusb implementation. Until these handhelds work with libusb users will need to configure udev.

We recently tried to tidy up the instructions for using the fall-back udev configuration, and this is documented in README.fedora - suggestions for improving README.fedora are welcome.

Until recently Fedora also carried a customised variant of 60-libpisock.rules, which was both broken for some devices and caused confusion when users went to the pilot-link mailing lists for help.

A key issue is that it's impossible to write a udev rule symlinking /dev/pilot that works for *all* handhelds on *all* machines (see bug #281641). What works for you will definitely fail for someone, somewhere. As you've discovered, some Palm handhelds use ttyUSB(x), while others use ttyUSB(x+1)... and this is further confused if you have another USB serial device which might create a ttyUSB device (making your odd port even, and so on).

So we now ship the unmodified upstream version of 60-libpisock.rules with instructions on how to modify it for your setup in README.fedora.

(In reply to comment #11)
> On a fully-patched FC8, I symlinked /etc/udev/rules.d/60-libpisock.rules and
> 60-pilot.rules to the respective .rules.fedora files in
> /usr/share/pilot-link/udev/. /dev/ttyUSB? and /dev/pilot files were created

Hmmm, was this the 60-libpisock.rules provided in the current F8 RPM? It shouldn't create a /dev/pilot symlink unless you modified it by hand.

I've just checked a fresh copy of pilot-link-0.12.2-21.fc8 - are you sure you don't have an .rpmnew around?


> BUS=="usb", SYSFS{product}=="Palm
> Handheld*|Handspring*",KERNEL=="ttyUSB[02468]", SYMLINK="pilot", GROUP="uucp",
> MODE="0660"

The SYSFS matching also causes a load of hassles because it relies on a non-guaranteed string from the hwdata package (in turn from another upstream). This string changed at least once over the life of F8 - it's not a robust mechanism for matching.

Sorry to sound so negative, but the impossibility of fixing the udev rules was one of the motivations for using libusb. If you follow the links in earlier comments you'll see the upstream pilot-link developer was trying to get m130s working with libusb, but was struggling to get hold of any hardware.
Comment 13 Ivana Varekova 2008-09-19 04:58:16 EDT
Hello, for now I think there is no solution how fix this problem for fc8 - but this is fixed in fc9 - so I'm closing this bug as nextrelease.
Comment 14 Kevin R. Page 2008-09-19 08:31:01 EDT
Ivana: which patch fixed it for F9? As far as I'm aware there hasn't been a fix applied upstream. We haven't done anything at the Fedora end to fix it, have we? - it's a compatibility problem specifically with the m130, not just the PolicyKit/hal/libusb stuff.

Brian/Adam: could you confirm this is fixed in F9, please? Re-open this bug if not and reset version to F9.

If there has been a Fedora patch to fix this it should certainly be pushed back upstream.
Comment 15 Kevin R. Page 2008-09-19 08:35:20 EDT
(Ivana: comment #11 is a bit of a red herring. If it were a valid bug - which it's not - it should be filed separately to this one. I suspect this bug is a USB "timing" bug similar to the recent Clie ones; unfortunately applying the Clie timings is reported not to work)
Comment 16 Brian Mury 2008-09-19 18:38:35 EDT
Kevin,

No, not fixed in F9. I'm still using pilot-link to sync my m130.
Comment 17 Kevin R. Page 2008-09-21 17:16:29 EDT
Ivana / Adam: please re-open and set version to F9.
Comment 18 Ivana Varekova 2008-09-22 06:02:22 EDT
Hello,
sorry for closing this (thanks Kevin for reopening it ).
Comment 19 Brian Mury 2008-12-29 15:37:04 EST
Still not working in F10.
Comment 20 Alex Butcher 2008-12-29 18:00:19 EST
Works almost out of the box with F10+all updates for me. Cradle configured as USB, timeout=2, device=/dev/ttyUSB0, Speed=57600.

The only tweak I needed to do was 'modprobe visor' in /etc/rc.d/rc.local
Comment 21 Brian Mury 2008-12-30 03:50:18 EST
Alex,

This bug is about libusb. Your use of 'modprobe visor' and device=/dev/ttyUSB0 indicate you are using the visor module, which means that you are not using libusb.
Comment 22 Alex Lancaster 2008-12-30 04:04:50 EST
(In reply to comment #19)
> Still not working in F10.

Updated version accordingly.  Sorry I can't help with direct debugging, not having that Palm model myself.
Comment 23 Bug Zapper 2009-11-18 05:13:06 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 24 Bug Zapper 2009-12-18 01:11:50 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 25 Brian Mury 2009-12-26 02:21:58 EST
This is still a problem with F11. I haven't tested it yet with F12 as I'm not yet running F12.
Comment 26 Brian Mury 2010-01-04 15:49:16 EST
I'm now running F12. This is still does not work with F12.

Can someone reopen this bug? I don't have permission to change the status.
Comment 27 Adam Stein 2010-01-04 16:12:13 EST
Since I was the original creator, I guess I can reopen it as long as somebody tells me exactly what I need to do.  For status, my only two choices are CLOSED or ASSIGNED.  If I set it to ASSIGNED, what should I set the other field to (currently set to WONTFIX)?

Never reopened a bug before, so I want to make sure I do it the proper way.
Comment 28 Alex Lancaster 2010-01-05 17:41:37 EST
(In reply to comment #27)
> Since I was the original creator, I guess I can reopen it as long as somebody
> tells me exactly what I need to do.  For status, my only two choices are CLOSED
> or ASSIGNED.  If I set it to ASSIGNED, what should I set the other field to
> (currently set to WONTFIX)?

ASSIGNED will fix it, but the other field will disappear (only set when CLOSED).
 
> Never reopened a bug before, so I want to make sure I do it the proper way.  

You can reopen but since pilot-link is more or less dead upstream:

http://www.pilot-link.org/pilot-link-0-12-4-pew-and-pas-release

this is unlikely to ever be fixed.  (But patches welcome).
Comment 29 Adam Stein 2010-01-06 07:31:08 EST
Changed version to 12 since Brian Mury states it still doesn't work.  Maybe somebody will submit a patch someday even if pilot-link is done.  Especially since this is a bug with libusb, not necessary with pilot-link itself.
Comment 30 Ivana Varekova 2011-01-05 03:35:03 EST
Thanks, fixed in pilot-link-0.12.5-4.fc15.
Comment 31 Ivana Varekova 2011-01-05 08:29:22 EST
Ehm, sorry it was typo(wrong bug number).
Comment 32 Ivana Varekova 2011-01-21 04:20:18 EST
Hello, 
please can you reproduce this bug with the latest versions of packages on rawhide?
Comment 33 Adam Stein 2011-01-28 18:11:18 EST
Ivana, I sent you an email but I haven't receive a reply, so I'll state my message here:

I see that you would like me to test with rawhide.  I'm currently
running Fedora 13.  Is that good enough for testing or is rawhide
radically different?  If I need to use rawhide, how do I go about
getting packages and will they work on Fedora 13?

Also, which packages should I be updating?

I'm afraid I'll need more precise instructions as to what you would like
me to do to upgrade the packages.
Comment 34 Alex Lancaster 2011-01-28 19:28:14 EST
(In reply to comment #33)
> Ivana, I sent you an email but I haven't receive a reply, so I'll state my
> message here:
> 
> I see that you would like me to test with rawhide.  I'm currently
> running Fedora 13.  Is that good enough for testing or is rawhide
> radically different?  If I need to use rawhide, how do I go about
> getting packages and will they work on Fedora 13?
> 
> Also, which packages should I be updating?
> 
> I'm afraid I'll need more precise instructions as to what you would like
> me to do to upgrade the packages.

I think she probably was wondering if you could rebuild the rawhide package locally on your Fedora 13 machine and then install them.  In any case, I went ahead and did some scratch builds for you, you can download the packages from koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2748486

click on the architecture you have and the rpms should be at the bottom of the list.
Comment 35 Adam Stein 2011-02-05 19:23:59 EST
Here's what I've done so far in trying to get the pilot-link to work (which hasn't).  Maybe one of the problems I'm having is preventing it from working:

1) Installed new version of pilot-link

    sudo rpm -U pilot-link-0.12.5-1.fc13.x86_64.rpm

Previously, I had pilot-link-0.12.4-7.fc13.x86_64.  Since I only had the pilot-link package installed, that's the only one I updated.

2) Tried to remove visor (didn't know if it needed to be removed).  Could not remove the visor module from the kernel.  Ran:

    sudo modprobe -r visor

No errors, but 'modprobe -l' still listed it.  Added:

    blacklist visor

to '/etc/modprobe.d/blacklist.conf' and rebooted.  'modprobe -l' still listed visor.

3) Removed udev rules I put into place.  I had the following rules to create '/dev/pilot':

BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring *", KERNEL=="ttyUSB[02468]", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="uucp", MODE="0666"

I commented that rule out and changed the original Pilot rule in '/usr/share/pilot-link/udev/60-libpisock.rules' so that the group is uucp:

ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0050", GROUP="uucp", MODE="0664"

lsusb still shows the Pilot when I hit the hot sync button (so I know it's ID vendor 0830 and product 50).

After changing the rules, I ran '/etc/init.d/udev-post reload'.  This results in the message:

    Retrigger failed udev events                               [  OK  ]

So I assume things loaded ok.

Running 'pilot-xfer -p usb: -l' resulted in the same problem as before, no connection.  I ran as myself and as root.  I can post another pilot-link debug like I did originally, but I thought I would run this by people first to make sure I did everything I was suppose to do or if there was some obvious error (like visor needs to be removed for USB to work).
Comment 36 Alex Lancaster 2011-02-06 01:09:37 EST
This may just be broken upstream (i.e. in pilot-link itself), and since upstream is more or less dormant and no new PalmOS 5.x devices are in production any longer, I suspect that this bug may never be fixed, except by somebody willing to debug it right down to the device level.  (which is well beyond me as packager).
Comment 37 Adam Stein 2011-02-08 19:27:58 EST
As long as visor continues to work, I can use that.  This is not critical.
Comment 38 Bug Zapper 2011-06-02 14:30:27 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 39 Brian Mury 2011-06-10 03:03:29 EDT
Not working in F15.
Comment 40 Alex Lancaster 2011-06-10 10:46:57 EDT
(In reply to comment #39)
> Not working in F15.

Bumping to F15.  However, I suspect that this bug may never be fixed, just to reiterate my comment #36.  Of course, any patches would be welcome.
Comment 41 Fedora Admin XMLRPC Client 2011-07-12 07:48:41 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 42 Peter Schiffer 2012-05-31 10:49:56 EDT
Hi guys,

what's the current status of this bug now?

As Alex said, I am afraid this never be fixed. So, without any new progress, I would close this bug as CANTFIX if you agree.

peter
Comment 43 Adam Stein 2012-05-31 18:49:57 EDT
Yes, I would say close as CANTFIX is there never will be one.  No point leaving it open.  If you can leave a reason for CANTFIX, make sure it's added so that anybody else seeing this issue will understand why it's not being fixed.
Comment 44 Peter Schiffer 2012-06-01 12:55:23 EDT
Thanks Adam.

I am closing this issue as CANTFIX, as we were unable the determine the root of this problem, upstream is gone and this kind of HW is getting old..

peter

Note You need to log in before you can comment on or make changes to this bug.