Red Hat Bugzilla – Bug 246128
[rhts] usb errors on boot up
Last modified: 2007-11-30 17:07:45 EST
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
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.
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?