Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 189854 - USB devices are getting disconnected: control timeout on ep0out
USB devices are getting disconnected: control timeout on ep0out
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-04-25 04:45 EDT by Sailaja
Modified: 2012-06-20 12:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 12:02:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
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 (13.11 MB, text/plain)
2006-04-25 04:45 EDT, Sailaja
no flags Details

  None (edit)
Description Sailaja 2006-04-25 04:45:25 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 
from "/var/log/messages":
"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
Actual results:
Devices were getting disconnected and couldn't connect back When H/W reset 
functionality was executed

Expected results:
Devices should be connected back

Additional info:
1) usbserial, uhci_hcd and ehci_hcd were loaded ("lsmod" lists these modules)
Comment 1 Sailaja 2006-04-25 04:45:48 EDT
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
Comment 2 John (J5) Palmieri 2006-04-25 10:26:02 EDT
Looks like a kernel driver issue.  Reassigning.
Comment 3 Pete Zaitcev 2006-04-25 13:40:51 EDT
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.
Comment 4 Sailaja 2006-04-26 00:50:07 EDT
One observation is, devices were getting detected without rebooting the system 
by removing hub cable from system USB port and connecting back.
Comment 5 Sailaja 2006-04-26 04:57:15 EDT
other error found while testing is "clear tt 3 (0380) error -32"
Comment 8 Sailaja 2006-05-26 06:18:50 EDT
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 
change this.
Comment 9 Jiri Pallich 2012-06-20 12:02:43 EDT
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.

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