Description of problem:
Can't sync my Treo 700p under Fedora 7. Hot syncing worked fine in FC6 and earlier.
Version-Release number of selected component (if applicable):
How reproducible: 100%
Steps to Reproduce:
1.Plug USB cable in
2.Hit hotsync button
3.
Actual results: Error message on Treo
The connection can not be established.
The gnome-pilot-settings windows pop up but nothing happens after that.
/var/log/messages has the following entry which seems to indicate that it's
trying to connect to it twice,
Sep 6 18:45:58 wasp kernel: usb 2-4: Handspring Visor / Palm OS converter now
attached to ttyUSB0
Sep 6 18:45:58 wasp kernel: usb 2-4: Handspring Visor / Palm OS converter now
attached to ttyUSB1
I've tried adding custom /etc/udev/10-visor.rules,
SUBSYSTEMS=="usb", ATTRS{product}=="Palm Handheld", KERNEL=="ttyUSB[13579]",
NAME="%k", SYMLINK="pilot tts/USB%n", GROUP="plugdev", MODE="0660"
This worked for a while Fedora 7 was new but it stopped working after some
updates. I've tried revising the rules with other rules that I've seen mentioned
in various posts on the web but nothing works now. I've also tried removing the
custom rules file. I've also tried adding myself to the uucp group, that had no
effect.
Expected results:
Additional info: Running 64 bit F7

the following /etc/udev/10-visor.rules works with kpilot configured to
/dev/pilot: (the rule is bound to a cerain user, but this is not a problem in my
system's configuration).
SUBSYSTEMS=="usb", ATTRS{product}=="Palm Handheld", KERNEL=="ttyUSB[13579]",
NAME="%k", SYMLINK="pilot", OWNER="krz", MODE="0660"
rpm versions:
Kernel: kernel-2.6.22.4-65.fc7
udev: udev-113-11.fc7

To confirm that it's not a configuration issue I booted into Scientific Linux 5,
the hotsync worked perfectly. This is a multiple boot system so I can switch
back and forth between many different distros. All are Redhat family, FC3-FC8
(both 32 and 64 bit versions) and SL5 (RHEL5). /home is shared between all
distros, only the root partitions are different.

A couple of comments:
The kernel update is the most likely culprit. I see that bjrosen tried booting
from an older kernel and it didn't fix the problem. Can he confirm that it
definitely used to work with that kernel? If not, is there an earlier kernel
that you could try?
There are now several reports of users having problems with Treo 700p's in
particular. This could just be that it's a common device, but I suspect timing
issues in Treo detection and device creation (i.e. udev).
If pilot-xfer works very reliably (i.e. no sensitivity to the timing of starting
pilot-xfer/sync operations) then you could see if gnome-pilot works if you (even
temporarily) disable hald when starting gnome-pilot. This triggers a different
path through the device detection code by polling usbfs.
If not, see the following link for a pilot-link library hack that might make a
difference -- NOTE: This hack is not recommended, but might help isolate this
bug as a usb timing issue.
http://mail.gnome.org/archives/gnome-pilot-list/2007-October/msg00011.html
Regards,
Matt Davey

It's definitely not a kernel issue. I just booted my FC6 partition with a
2.6.21.5 kernel, syncing doesn't work. It was something else in that update that
broke it.
BTW, the Treo 700p is the dominant Palm device today, that's why you are seeing
multiple reports from Treo owners. It has EVDO which gives it good internet
speed, it's predecessor (the 650) didn't have EVDO so anyone who had one of
those would have traded it in. It's successor, the 755p, is essentially
identical except that they changed the antenna so there was no incentive to
upgrade and as such there aren't that many of them out there.
The Treo has been the smartphone of choice for Linux users because of it's
ability to sync with Linux (until now) and because it can run ssh which gives
you the ability to log into a Linux system from your phone.

I have a Palm Treo 680 (unlocked). I installed Fedora 8t3 and I am having the
same problems in syncing my device. In fact, I can't even get Gnome Pilot to
see my device while using the setup wizard. It seems that after Fedora Core 6,
I began having problems with syncing my device with Fedora 7 and now with the
test versions of Fedora 8.

FYI, I had reinstalled Fedora 7 on my IBM ThinkPad T-30 a couple of days ago
without updating the kernel. I also trolled around on the internet and created
the typical 10-Visor file necessary to get my Palm Treo 680 syncing. I was
successful in doing this until yesterday (10/9/07)when I updated my computer
through the update manager. My desktop is Gnome and there is something in this
update that causes Gnome Pilot to no loger sync properly with my device. This
certainly needs to be checked out and fixed before the final release of Fedora
8 in November.

I think I've identified the update that breaks FC6. I did a fresh install of 64
bit FC6. The syncing worked with the fresh install. I then gradually did the
updates, checking that syncs worked after each set. Occasionally I had to kill
and restart the gpilotd daemon but I was able to do syncs after most of the
updates. When I got to the udev update the hotsync stopped working. Killing and
restarting the daemon didn't help, neither did logging out and back in. Here is
the update that breaks hotsyncing on FC6,
Oct 11 03:20:40 Updated: udev.x86_64 095-17.fc6

That's some progress anyway!
A couple of things to check:
1. does the 'visor' module load? (I presume you're not using libusb 'usb:'
syncing...).
2. what shows up with dmesg? Do you see the creation of the ttyUSB devices?
3. Do they have the right permissions?

To reporters:
Is this is a problem where you are using /dev/pilot and it gets linked to the
wrong ttyUSB device?
If so, try setting your sync device to /dev/ttyUSB0, or /dev/ttyUSB1 as
appropriate. Only one of these can be used for syncing, and udev is not always
consistent about which order they get assigned. This may be the cause of the
apparent regression. A little more explanation from the udev crew would have
been illuminating!
A better fix for fedora would be to migrate to using libusb syncing, which
avoids the use of the ttyUSB devices and visor module altogether. libusb
syncing is 'a little bit beta' in pilot-link, but I note that Ubuntu has already
gone that route (I doubt the pilot-link maintainer is too happy about this, but
it is evidence that the usbserial route is troublesome for many users).

In response to #19 and #18. This is NOT a problem with udev rules. In my case,
the symptoms are identical when using usb: (after blacklisting the visor module)
/dev/pilot, or /dev/ttuUSB1 (/dev/ttyUSB0 goes nowhere). In all cases, the
initial connection gets established, but syncing never completes. If it helps, I
can attach the output from gpilotd to confirm this. Another point - syncing DOES
work with a different palm pilot (Tungsten E).
Looking at the changelog for udev, it seems that the most likely candidate is
the change in timing for the USB port. Or am I missing something in the
changelog that would cause a regression in the context of udev rules that
continues to work fine for other palm devices?

I did an install of the latest Gutsy release candidate, syncing worked fine
there. With Gutsy I had to select usb: to make it work.
I then did a clean install of Fedora 8 Test 3, did all the updates and then
tried it. With usb: selected I got an error message saying that I was using the
new style libusb syncing but that I had the old style visor module loaded. I
tried all of the other options, ttyUSB0, ttyUSB1, ttyS0, ttyS1 and pilot, none
of them worked,
The Ubuntu approach seems to work. Fedora should switch to that method. I'm
going to try blacklisting visor and rebooting.

This has been observed as a udev regression twice, unrelated to visor/usbserial
udev rules. I suggest this gets reassigned to udev. Perhaps they can work with
one of the reporters to find out what's going on.

I've made some updated packages via koji for pilot-link on F-8 at bug #280251
comment #12 which hopefully fix (or help) the syncing situation when using the
visor technique. Please let me know if they work on that bug. I can also make
F-7 packages if necessary.
Note that the configuration files (e.g. in /etc/udev/rules.d) won't replace your
current configs, so you'll need to move them if you want to test things. You
should also move aside and backup any hand-crafted files you made to make sure
they aren't interfering with the configs from the package.

Many of these comments sound like they could be permission issues; for an
updated attempt to work around these using libusb (pilot-xfer -p usb: ) and
PolicyKit take a look at bug #280251 comment #110 (the manual changes are still
required with pilot-link-0.12.2-18.fc8)
There's an updated REAME.Fedora in recent pilot-link packages which may help
with the visor module method, though libusb should be seen as the preferred
long-term solution.
If the methods in bug #280251 comment #110 are successful for you I'd suggest
marking this bug as a duplicate of it.
There was a specific Zire22 issue: see bug #431498.
The - as far as I can tell, unsolvable - problems of using the visor modules
with udev should be directed to bug #158809.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.
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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 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.

Note

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