Bug 151426 - Treo 650 is unable to sync, kernel outputs "control timeout on ep0in"
Summary: Treo 650 is unable to sync, kernel outputs "control timeout on ep0in"
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gnome-pilot (Show other bugs)
(Show other bugs)
Version: 4.0
Hardware: i386 Linux
Target Milestone: ---
: ---
Assignee: Matthew Barnes
QA Contact:
Whiteboard: RHEL4U3NAK
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-17 19:24 UTC by Richard Monk
Modified: 2008-08-02 23:40 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-05 20:05:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Richard Monk 2005-03-17 19:24:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Mnenhy/0.7.1

Description of problem:
I attached the Treo 650 to both an IBM X31 laptop and IBM S50 workstation in an effort to configure and sync a Treo 650 palm smartphone.  In both cases, the kernel reports the same information:

[ Plug in device, hit 'hotsync' ]
usb 3-1: new full speed USB device using address 6
visor 3-1:1.0: Handspring Visor / Palm OS converter detected
usb 3-1: Handspring Visor / Palm OS converter now attached to ttyUSB0
usb 3-1: Handspring Visor / Palm OS converter now attached to ttyUSB1

[ run any app, including pilot-xfer, install-user, etc.. ]
usb 3-1: control timeout on ep0in

The app will hang for several seconds until the kernel error appears, then, for example, install-user will exit with the message:
Error accepting data on /dev/ttyUSB1

I tested a Treo 600 with no problem, as well as tested an HP ZD7000 laptop running Gentoo (kernel 2.6.10) which exhibited the same bug.  A similar bug has been reported on FC3, #128602

Other devices work fine, and the USB hardware and drivers seem unaffected.

rmmod/insmod of the drivers did no good, as did attempts to disable ACPI and APIC (uniprocessor machine).  In each case, the error was identical.

It appears that there is a bug in the Treo 650 hardware itself that it will not accept a control and bulk message at the same time.  Possibly there is a way to lock out control messages during data transfer for this device?

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

How reproducible:

Steps to Reproduce:
1. Plug in Treo 650
2. Hit Hotsync on Treo
3. Attempt to connect/sync device using pilot-xfer tools

Actual Results:  Listening to port: /dev/ttyUSB1

   Please press the HotSync button now... 
   Error accepting data on /dev/ttyUSB1

Expected Results:  Installation of user on Palm after connecting.

Additional info:

Comment 4 Jens Ziemann 2005-03-22 10:23:07 UTC
Also doesn´t work with my brandnew PalmOne Tungsten T5 which has the same OS as
the Treo 650 :-(
Have tried it with the latest FC3 kernel, still does not work...

Comment 5 Rod Nayfield 2005-04-24 18:18:29 UTC
I don't know if this is really a kernel issue, at least in all cases.  Perhaps
newer treos (mine was purchased yesterday) may have subtle changes.

Gnome-pilotd would not sync.  I noticed that I could use pilot-xfer like so:
pilot-xfer -p /dev/pilot -l  (I have /dev/pilot set up with udev)

to list the contents of the treo.  Further investigation revealed that kpilotd
was working to sync the treo.

I added one line to /usr/share/gnome-pilot/devices.xml
 <device vendor_id="0830" product_id="0061" />

This fixed the problem for me on kernel 2.6.9-5.0.3.EL.  


Comment 6 Pete Zaitcev 2005-05-03 22:47:50 UTC
Mental note: Spot reports that his 650 works dandy with 2.6.11-1.1240_FC4.

Comment 7 Rod Nayfield 2005-05-04 12:56:15 UTC
Also - while I can sync, the gpilot applet does not present status.  (No pop-up,
nor does the panel icon turn green).

So the hardware ID may be coded in two places within the gnome pilot package...

Comment 8 Richard Monk 2005-05-04 14:24:37 UTC
After seeing the success with FC4, I tried it myself.  

My current testing with IBM, Dell, and HP hardware shows it doesn't seem to be
hardware related, but I haven't tried all combinations of hardware/OS yet.

Current tests:
OS      Kernel Release             Status
FC4     2.6.11-1.1275_FC4          Syncs correctly!
FC3     2.6.11-1.14_FC3smp         ep0in timeout, failure to sync
RHEL4   2.6.9-5.0.5.ELsmp          ep0in timeout, failure to sync

UPDATE: In verifying all of this just now, after the sync in FC4, the device
WORKS.  Even after a hard reset of the 650, all kernels are able to sync (full
backup/restores, a stressful connection) with no problems at all. 

Could the problem actually be that the FC4 kernel handles the configuration
differently or it does something to the Treo 650's USB stack to make it work
correctly?  I'm baffled.  I have another 650 that's out, it could not sync, so
I'll get a hold of that and test to see that:

A. Systems that could sync to 'fixed' 650 cannot sync (no change to the OS has
fixed it)

B. Syncing to FC4, then to any other OS, allows syncing (that the FC4-650
interaction is 'fixing' the 650)

I'll try to find the time to look through all the changelogs, this may be
another symptom of a now-squished bug?

Comment 9 Richard Monk 2005-05-04 14:31:00 UTC
The "fresh" Treo 650 works flawlessly.  RHEL4 and FC3 (kernel vers above) seem
to work.

5.0.5 has a bugfix/change?

Comment 10 Jens Ziemann 2005-05-04 16:04:38 UTC
what are you syncing with - Treo 650 using gpilotd to evolution?

Comment 11 Richard Monk 2005-05-04 17:23:39 UTC
I am using pilot-xfer or jpilot.

Comment 12 Jens Ziemann 2005-05-04 17:27:08 UTC
somebody successfully tried gpilotd and evolution yet??

Comment 13 Rod Nayfield 2005-05-04 17:39:10 UTC


I added one line to /usr/share/gnome-pilot/devices.xml
 <device vendor_id="0830" product_id="0061" />

This fixed the problem for me on kernel 2.6.9-5.0.3.EL.  

I have been syncing ever since adding that one line to devices.xml.   

Comment 14 Dave Jones 2005-05-10 00:01:27 UTC
If that works for everyone, perhaps reassigning this bug to gnome-pilot makes
sense ?

Comment 15 Shane Owenby 2005-05-12 07:22:54 UTC
FWIW, RHEL 4 Desktop (up2date as of May 11th 2005) including kernel 
2.6.9-5.0.5.EL worked out of the box by adding:
Te one line to /usr/share/gnome-pilot/devices.xml
 <device vendor_id="0830" product_id="0061" />

I also added the below to /etc/security/console.perms
<console>  0600 <usb1>       0660 shane.uucp
<console>  0600 <usb0>       0660 shane.uucp

I would suggest changing this to gnome-pilot.  Best, Shane

Comment 21 Richard Monk 2005-06-22 18:34:43 UTC
I have noticed a strange issue now with "working" environments.  Normally, to
sync (because of udev), you must hit "sync" on the device, then "sync" on the
software.  The problem arises if the user waits too long to hit "sync" on the
software, the "control timeout" bug resurfaces.  If they hit it very very soon
(<1sec) after hitting sync on the device (probably -right- after udev creates
the files) it works correctly, although sometimes large transfers will time out
or crash the software. (This was seen with pilot-xfer doing a backup and jpilot
doing a large sync)

I have verified this happens with IBM laptops X31 and T42 with current RHEL4
kernel (2.6.9-11)

Anyone else see this and know a workaround/solution?

Comment 27 Jens Ziemann 2005-10-12 14:35:12 UTC
Hi all,

just tried with FC4 kernel 2.6.13-1.1526_FC4 ... plugging the USB cable into the
PC (Dell Latitude D800) makes the Palm go directly to Nirvana (reproducable
within 3-4 sec.)

Comment 28 Dave Malcolm 2005-10-21 22:39:05 UTC
Thanks for the report; please open FC4 problems as a separate bug (there are
various problems on FC4; owing to a change in the underlying pilot-link package)

Comment 30 Richard Monk 2005-10-26 16:55:21 UTC
Using the latest RHEL4-U2 kernel (2.6.9-22), trying to sync large amounts of
data (like a large addressbook) creates the same issue, with a control timeout.
 pilot-xfer then segfaults.

Is there any fix for this?  Since we've started having users with Treo650s,
they're putting a lot of data on them and it's causing a lot of headaches since
we can't back them up.

Comment 33 Richard Monk 2005-11-11 17:04:41 UTC
I discovered that if you rmmod ehci_hcd (disabling USB 2) it works just fine. 
Seems that the bug is only in the USB 2 driver in the PalmOS.

Is there a way to disable USB 2 for a particular device?

Comment 34 Per Sjoholm 2005-11-26 16:06:14 UTC
I have a simular problem, using a USB scanner (HP 6200) on kernel
2.6.9-22.0.1.EL. connected to a usb1.
It works OK in latest gentoo 2.6.14 (i haven't tested the earlier ones)
A search for 'USB control timeout' on kernel.org show the same problem before
version 2.6.10-rc? Can this be a kernel/usb or libusb problem ?

Comment 35 Daniel Riek 2006-03-13 17:13:55 UTC
This has low priority for now, but it still should be tracked. If it indeed is
the kernel/USB related problem, it might have broader impact. Plese try to scope
out if this needs to get moved to the kernel.

Clearing all ACKs

Comment 38 RHEL Product and Program Management 2006-09-05 19:54:42 UTC
The component this request has been filed against is not planned for inclusion
in the next update. The decision is based on weighting the priority and number
of requests for a component as well as the impact on the Red Hat Enterprise
Linux user-base: other components are considered having higher priority and the
number of changes we intend to include in update cycles is limited.

Comment 39 RHEL Product and Program Management 2006-09-05 20:05:26 UTC
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 

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