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)
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 change this.
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.