Bug 189854 - USB devices are getting disconnected: control timeout on ep0out
Summary: USB devices are getting disconnected: control timeout on ep0out
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-04-25 08:45 UTC by Sailaja
Modified: 2012-06-20 16:02 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 16:02:43 UTC
Target Upstream Version:
Embargoed:


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 08:45 UTC, Sailaja
no flags Details

Description Sailaja 2006-04-25 08:45:25 UTC
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 
1-1.1.2)
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 08:45:48 UTC
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 14:26:02 UTC
Looks like a kernel driver issue.  Reassigning.

Comment 3 Pete Zaitcev 2006-04-25 17:40:51 UTC
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 04:50:07 UTC
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 08:57:15 UTC
other error found while testing is "clear tt 3 (0380) error -32"

Comment 8 Sailaja 2006-05-26 10:18:50 UTC
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 16:02:43 UTC
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.