Bug 246128 - [rhts] usb errors on boot up
[rhts] usb errors on boot up
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Kernel Manager
Martin Jenner
http://rhts.lab.boston.redhat.com/cgi...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-28 14:18 EDT by Don Zickus
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-06 18:57:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Don Zickus 2007-06-28 14:18:20 EDT
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 18:57:08 EDT
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 10:18:40 EDT
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?


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