Bug 246128

Summary: [rhts] usb errors on boot up
Product: Red Hat Enterprise Linux 5 Reporter: Don Zickus <dzickus>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED NOTABUG QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
URL: http://rhts.lab.boston.redhat.com/cgi-bin/rhts/test_log.cgi?id=208829
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-06 22:57:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Don Zickus 2007-06-28 18:18:20 UTC 
Description of problem:

In my continuous quest to eliminate boot warnings, fails, and errors, I have
discovered usb issues.

usb 1-1: string descriptor 0 read error: -71
usb 1-1: string descriptor 0 read error: -71
usb 1-1: can't set config #1, error -71
usb 5-8: device descriptor read/64, error -71

Version-Release number of selected component (if applicable):
kernel-2.6.18-32.el5

How reproducible:

Most likely machine specific.

Hostname                = intel-d3x1311-01.rhts.boston.redhat.com
Kernel Version          = 2.6.18-32.el5PAE
Machine Hardware Name   = i686
Processor Type          = i686
uname -a output         = Linux intel-d3x1311-01.rhts.boston.redhat.com
2.6.18-32.el5PAE #1 SMP Tue Jun 26 15:07:26 EDT 2007 i686 i686 i386 GNU/Linux
Swap Size               = 1983 MB
Mem Size                = 1002 MB
Number of Processors    = 2


Steps to Reproduce:
1. install kernel and reboot
2.
3.
  
Actual results:
warnings, failures, errors

Expected results:
no warnings, failures, errors

Additional info:
see url for full dmesg log
Comment 1 Pete Zaitcev 2007-08-06 22:57:08 UTC 
I don't think I can do anything here. Sorry, Don. But I'll look at the spec
once again and re-check if we're doing something wrong.

It appears that EHCI gets initialized when Avocent (on context of a child of
udev, running modprobe) continues to initialize. We were lucky and it happened
when HID was fetching string descriptors. Then, for some reason, transmission
failed. It would be understandable if EHCI tried to take over the port, but
the device were low-speed, like a keyboard. The details of EHCI taking over
is something that I do not know well, see above.

The odd thing is how Avocent is actually a High-Speed device, I know that.
Note that it has storage slots. It should have been taken over by EHCI.
Maybe the cable is too long or too thin.

The right thing to do is to load ehci_hcd first and its component controller
drivers later. This way EHCI drives everything that turned out to be capable
of High-Speed, and the companion collects what fell out of the bag. But
something prevents us from doing that... I don't remember, maybe we ought
to ask Bill Nottingham. It's in mkinitrd somewhere, I believe.
Comment 2 Don Zickus 2007-08-07 14:18:40 UTC 
I appreciate you looking at this Pete.  The problem may not be the software, but
is there anything you can recommend (besides the mkinitrd thing) that we could
try?  Perhaps swap out usb cables, change some sort of configuration, upgrade
the BIOS?