Red Hat Bugzilla – Bug 189854
USB devices are getting disconnected: control timeout on ep0out
Last modified: 2012-06-20 12:02:43 EDT
Description of problem:
USB devices (mobiles) are getting disconnected after some no. of H/W reset
tests (ex: 20-30 iterations). The below is the error observed
"Apr 24 20:59:06 aims-pc-91 kernel: usb 1-1.1.1: control timeout on ep0out
Apr 24 20:59:06 aims-pc-91 kernel: usb 1-1.1.1: device not accepting address
17, error -110"
Devices used: Sony Ericsson Z1010 mobiles
Version-Release number of selected component (if applicable):
RHEL4 WS - Update3 (kernel version: 2.6.9-34)- USB driver
How reproducible: Quite often
Steps to Reproduce:
1. Devices (sony ericsson Z1010 mobiles) were at 4th Level
2. Executed H/W reset automation tests on first 2 mobiles (usb 1-1.1.1 and usb
3. After some number of iterations (ex: after 20-30 iterations), mobiles were
disconnected with the above specified error and couldn't connecte back
4. Only after rebooting the system, devices were connecting back
Devices were getting disconnected and couldn't connect back When H/W reset
functionality was executed
Devices should be connected back
1) usbserial, uhci_hcd and ehci_hcd were loaded ("lsmod" lists these modules)
Created attachment 128186 [details]
Contains out put of "/var/log/messages" and "/proc/bus/usb/devices": contains device disconnection problem for mobiles usb 1-1.1.1 and usb 1-1.1.2
Looks like a kernel driver issue. Reassigning.
RHEL bugs have to be routed through Issue-Tracker.
But from the community perspective, I have a couple of comments:
- Using usbserial_generic is crazy. It cannot work, the driver is known to hang.
- Loading AIMSUSB taints. The tty API in kernel is tricky, and placing shims
on it is liable to cause all sorts of misbehavior.
I'm wondering what kind of genius designed this software stack.
Maybe it would be more productive to ask him what he was thinking.
One observation is, devices were getting detected without rebooting the system
by removing hub cable from system USB port and connecting back.
other error found while testing is "clear tt 3 (0380) error -32"
I would appreciate to change this TR Priority to "HIGH" from "normal", since
it is a show stopper for our product. Unfortunately I don't have privileges to
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.