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): kernel-2.6.9-5.0.3.EL How reproducible: Always 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:
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...
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. -Rod
Mental note: Spot reports that his 650 works dandy with 2.6.11-1.1240_FC4.
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...
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?
The "fresh" Treo 650 works flawlessly. RHEL4 and FC3 (kernel vers above) seem to work. 5.0.5 has a bugfix/change?
what are you syncing with - Treo 650 using gpilotd to evolution?
I am using pilot-xfer or jpilot.
somebody successfully tried gpilotd and evolution yet??
Jens, Yes. 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.
If that works for everyone, perhaps reassigning this bug to gnome-pilot makes sense ?
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 <usb0>=/dev/ttyUSB0 <usb1>=/dev/ttyUSB1 and <console> 0600 <usb1> 0660 shane.uucp <console> 0600 <usb0> 0660 shane.uucp I would suggest changing this to gnome-pilot. Best, Shane
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?
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.)
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)
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.
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?
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 ?
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
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.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.