Bug 281641 - Treo Hot Sync doesn't work on Fedora 7
Treo Hot Sync doesn't work on Fedora 7
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pilot-link (Show other bugs)
7
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Ivana Varekova
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-06 19:03 EDT by Joshua Rosen
Modified: 2013-02-08 13:58 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 22:20:49 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)

  None (edit)
Description Joshua Rosen 2007-09-06 19:03:45 EDT
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
Comment 1 Joshua Rosen 2007-09-19 12:05:03 EDT
I tried it on 32 bit Fedora 7, it doesn't work there either so it's not a 64 bit
issue.
Comment 2 Thomas 2007-09-25 20:48:38 EDT
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.
Comment 3 Krzysztof Rzadca 2007-10-01 10:24:21 EDT
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
Comment 4 Matthew Barnes 2007-10-02 10:59:38 EDT
Is this problem still present on Fedora 8 Test 2 or later?
Comment 5 Joshua Rosen 2007-10-02 13:08:19 EDT
I'll give F8 a try in a couple of days. I'm out of town, be back tommorow.
Comment 6 Joshua Rosen 2007-10-04 09:03:17 EDT
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
Comment 7 Matthew Barnes 2007-10-04 10:14:09 EDT
Thanks for responding.

CC'ing Matt Davey for this one.
Comment 8 Joshua Rosen 2007-10-04 10:48:53 EDT
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
Comment 9 Joshua Rosen 2007-10-04 11:47:59 EDT
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.
Comment 10 Matt Davey 2007-10-05 06:54:26 EDT
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
Comment 11 Joshua Rosen 2007-10-05 08:45:24 EDT
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.
Comment 12 Jeffrey D. Yuille 2007-10-06 17:42:26 EDT
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. 
Comment 13 Jeffrey D. Yuille 2007-10-10 11:38:36 EDT
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. 
Comment 14 Joshua Rosen 2007-10-11 03:37:41 EDT
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
Comment 15 Matt Davey 2007-10-11 05:25:16 EDT
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?
Comment 16 Manuel Morales 2007-10-11 14:14:28 EDT
I was also unable to sync a Treo 700p in F7. Reverting to
udev-106-4.fc7.x86_64.rpm allows successful hotsync again!
Comment 17 Matthew Barnes 2007-10-11 14:56:52 EDT
Based on these findings I'm reassigning the bug to udev.
Comment 18 Harald Hoyer 2007-10-12 02:53:13 EDT
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.
Comment 19 Matt Davey 2007-10-12 03:47:43 EDT
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).
Comment 20 Manuel Morales 2007-10-12 07:08:50 EDT
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?
Comment 21 Oscar Valdez 2007-10-13 21:30:11 EDT
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.
Comment 22 Joshua Rosen 2007-10-14 19:03:07 EDT
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.
Comment 23 Joshua Rosen 2007-10-14 19:18:37 EDT
I tried blacklising visor, it didn't help. I then tried installing
libopensync-plugin-palm. That didn't help either.
Comment 24 Matt Davey 2007-10-15 04:48:02 EDT
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.
Comment 25 Michael Shinn 2007-10-17 16:18:14 EDT
I can confirm that it doesn't work on Treo 650s either.  So this is not just a
Treo 700* problem.
Comment 26 Joshua Rosen 2007-11-07 22:51:07 EST
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.
Comment 27 Gilboa Davara 2007-11-14 08:38:45 EST
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
Comment 29 Gilboa Davara 2007-11-14 11:24:45 EST
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
Comment 30 Andrew 2007-11-15 21:41:50 EST
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.
Comment 31 Manuel Morales 2007-11-20 11:52:45 EST
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!
Comment 32 Alex Lancaster 2007-11-27 04:47:09 EST
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.
Comment 33 Kevin R. Page 2008-03-07 19:57:10 EST
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.
Comment 34 Bug Zapper 2008-05-14 10:16:01 EDT
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
Comment 35 Bug Zapper 2008-06-16 22:20:47 EDT
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.