Bug 281641

I tried it on 32 bit Fedora 7, it doesn't work there either so it's not a 64 bit
issue.

This is failing for me too after upgrading from FC6 to F7.

I have added the udev rule and can now sync using pilot-xfer.  This can only be
done once gpilotd has been killed.

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

Is this problem still present on Fedora 8 Test 2 or later?

I'll give F8 a try in a couple of days. I'm out of town, be back tommorow.

I tried 64 bit F8 Test2 with all of the current updates. Hot-syncing is still
broken. The Treo reports that the connection can not be established. Here is the
report from /var/log/messages


Oct  4 04:36:47 wasp kernel: usb 3-4: new full speed USB device using ohci_hcd
and address 4
Oct  4 04:36:47 wasp kernel: usb 3-4: configuration #1 chosen from 1 choice
Oct  4 04:36:48 wasp kernel: usbcore: registered new interface driver usbserial
Oct  4 04:36:48 wasp kernel: drivers/usb/serial/usb-serial.c: USB Serial support
registered for generic
Oct  4 04:36:48 wasp kernel: usbcore: registered new interface driver
usbserial_generic
Oct  4 04:36:48 wasp kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core
Oct  4 04:36:48 wasp kernel: drivers/usb/serial/usb-serial.c: USB Serial support
registered for Handspring Visor / Palm OS
Oct  4 04:36:48 wasp kernel: drivers/usb/serial/usb-serial.c: USB Serial support
registered for Sony Clie 3.5
Oct  4 04:36:48 wasp kernel: drivers/usb/serial/usb-serial.c: USB Serial support
registered for Sony Clie 5.0
Oct  4 04:36:48 wasp kernel: visor 3-4:1.0: Handspring Visor / Palm OS converter
detected
Oct  4 04:36:48 wasp kernel: usb 3-4: Handspring Visor / Palm OS converter now
attached to ttyUSB0
Oct  4 04:36:48 wasp kernel: usb 3-4: Handspring Visor / Palm OS converter now
attached to ttyUSB1
Oct  4 04:36:48 wasp kernel: usbcore: registered new interface driver visor
Oct  4 04:36:48 wasp kernel: drivers/usb/serial/visor.c: USB HandSpring Visor /
Palm OS driver
Oct  4 04:36:56 wasp kernel: usb 3-4: USB disconnect, address 4
Oct  4 04:36:56 wasp kernel: visor ttyUSB0: Handspring Visor / Palm OS converter
now disconnected from ttyUSB0
Oct  4 04:36:56 wasp kernel: visor ttyUSB1: Handspring Visor / Palm OS converter
now disconnected from ttyUSB1
Oct  4 04:36:56 wasp kernel: visor 3-4:1.0: device disconnected
Oct  4 04:36:56 wasp kernel: usb 3-4: new full speed USB device using ohci_hcd
and address 5
Oct  4 04:36:56 wasp kernel: usb 3-4: configuration #1 chosen from 1 choice
Oct  4 04:36:56 wasp kernel: visor 3-4:1.0: Handspring Visor / Palm OS converter
detected
Oct  4 04:36:56 wasp kernel: usb 3-4: Handspring Visor / Palm OS converter now
attached to ttyUSB0
Oct  4 04:36:56 wasp kernel: usb 3-4: Handspring Visor / Palm OS converter now
attached to ttyUSB1
Oct  4 04:39:08 wasp kernel: usb 3-4: USB disconnect, address 5
Oct  4 04:39:08 wasp kernel: visor ttyUSB0: Handspring Visor / Palm OS converter
now disconnected from ttyUSB0
Oct  4 04:39:08 wasp kernel: visor ttyUSB1: Handspring Visor / Palm OS converter
now disconnected from ttyUSB1
Oct  4 04:39:08 wasp kernel: visor 3-4:1.0: device disconnected
Oct  4 04:39:09 wasp kernel: usb 3-4: new full speed USB device using ohci_hcd
and address 6
Oct  4 04:39:09 wasp kernel: usb 3-4: configuration #1 chosen from 1 choice
Oct  4 04:39:09 wasp kernel: visor 3-4:1.0: Handspring Visor / Palm OS converter
detected
Oct  4 04:39:09 wasp kernel: usb 3-4: Handspring Visor / Palm OS converter now
attached to ttyUSB0
Oct  4 04:39:09 wasp kernel: usb 3-4: Handspring Visor / Palm OS converter now
attached to ttyUSB1
Oct  4 04:39:58 wasp yum: Installed: tcsh - 6.15-1.fc8.x86_64#000

Thanks for responding.

CC'ing Matt Davey for this one.

The hotsync is now broken on FC6. It was fine, I did an update, and now it
doesn't work anymore. I did a hotsync, it worked, then I did an update and
rebooted. After the reboot it didn't work anymore. I tried the usual trick of
killing the daemon and then letting it restart, it didn't help. I also tried
booting into an older kernel, that didn't help either. Here is the contents of
yum.log, I don't see anything obvious that would account for the problem.

Oct 04 10:17:37 Updated: php-common.i386 5.1.6-3.7.fc6
Oct 04 10:17:38 Updated: php-pdo.i386 5.1.6-3.7.fc6
Oct 04 10:17:43 Updated: httpd.i386 2.2.6-1.fc6
Oct 04 10:17:46 Updated: php-cli.i386 5.1.6-3.7.fc6
Oct 04 10:18:03 Updated: xfsprogs.i386 2.9.3-1.fc6
Oct 04 10:18:04 Updated: t1lib.i386 5.1.1-3.fc6
Oct 04 10:18:26 Installed: kernel-PAE.i686 2.6.22.7-57.fc6
Oct 04 10:18:27 Updated: iptables.i386 1.3.8-2.1.fc6
Oct 04 10:18:28 Updated: iptables-ipv6.i386 1.3.8-2.1.fc6
Oct 04 10:18:28 Updated: php.i386 5.1.6-3.7.fc6
Oct 04 10:18:28 Updated: php-mysql.i386 5.1.6-3.7.fc6
Oct 04 10:18:32 Updated: kernel-headers.i386 2.6.22.7-57.fc6
Oct 04 10:18:44 Installed: kernel-PAE-devel.i686 2.6.22.7-57.fc6
Oct 04 10:18:45 Installed: kmod-nvidia-PAE.i686 100.14.19-1.2.6.22.7_57.fc6
Oct 04 10:18:47 Updated: xorg-x11-drv-nvidia.i386 100.14.19-2.lvn6

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?

I was also unable to sync a Treo 700p in F7. Reverting to
udev-106-4.fc7.x86_64.rpm allows successful hotsync again!

Based on these findings I'm reassigning the bug to udev.

All udev rules with "even" and "odd" numbers are wrong. period.
udev: WONTFIX. pilot-link can include those rule files, if they want to cope
with the bugs.

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 can't hotsync with a Palm Z22, either.

When I connect the Palm, these are the messages:

kernel: usb 2-1: new full speed USB device using ohci_hcd and address 21
kernel: usb 2-1: configuration #1 chosen from 1 choice
kernel: visor 2-1:1.0: Handspring Visor / Palm OS converter detected
kernel: usb 2-1: Handspring Visor / Palm OS converter now attached to ttyUSB0
kernel: usb 2-1: Handspring Visor / Palm OS converter now attached to ttyUSB1

When I press the Hotsync button, these are the messages:

kernel: usb 2-1: USB disconnect, address 21
kernel: visor ttyUSB0: Handspring Visor / Palm OS converter now disconnected
from ttyUSB0
kernel: visor ttyUSB1: Handspring Visor / Palm OS converter now disconnected
from ttyUSB1
kernel: visor 2-1:1.0: device disconnected

Then, it'll automatically reconnect with a higher address, but without hotsyncing.

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.

I tried blacklising visor, it didn't help. I then tried installing
libopensync-plugin-palm. That didn't help either.

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 can confirm that it doesn't work on Treo 650s either.  So this is not just a
Treo 700* problem.

Is anyone working on this bug?. It still doesn't work in F8 with all of the
current updates. It's a real pain having to boot into SL5 or Ubuntu just to sync
my Treo.

It doesn't look like a udev problem to me.
Creating a static device nods in /etc/dev/ttyUSB? didn't seem to solve the problem.

- Gilboa

In reply to Comment #27:

Does the fix suggested in Comment #16 work?

For i386:
rpm -Uvh --oldpackage
http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/udev-106-4.fc7.i386.rpm

For x86_64
rpm -Uvh --oldpackage
http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Fedora/x86_64/os/Fedora/udev-106-4.fc7.x86_64.rpm

I seem to be hitting another problem... even with udev out of the way (read:
static device nodes) gpiliot syncs only once every 3-4 tries.

Please ignore my previous comment.

- Gilboa

After following comment 3 (the udev rule) and reverting both udev and kernel to
the oldest, original fc7 packages, I have a Treo (650 or 700p?) working again.

Using the latest version of udev (udev-116-3.fc7) and pilot-link
(pilot-link-0.12.2-6.fc7) from updates-testing fixes the issue for me!

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.