Red Hat Bugzilla – Bug 150605
USB ports not recognized as v. 2.0
Last modified: 2015-01-04 17:17:29 EST
Description of problem:
USB ports worked as expected in several builds of FC2. Upgraded in
place to kernel-smp-2.6.10-1.667_FC3 and then
kernel-smp-2.6.10-1.770_FC3. In both builds the USB ports are no
longer recognized as 2.0 capable but are seen as only 1.1
A DVD writer device works but is very slow (of course).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
USB ports recognized as 1.1, uhci_hcd driver loaded but not ehci_hcd
USB ports should be recognized as high-speed (2.0) and ehci_hcd driver
Created attachment 111789 [details]
output of lsusb -v
Created attachment 111790 [details]
output of lspci -v
Created attachment 111791 [details]
from kernel log
lines from kernel log when I attach dvd writer
do you have the latest version of hotplug installed ?
(stupid question) -- the device is plugged into a usb2.0 capable port ?
It was usb2.0 capable when I was on FC2.
Maybe it devolved.
I have the same problem on 2 different machines. On my Thinkpad T40,
the stick goes in and the light blinks for ever. It never mounts. If
I rmmod ehci_hcd, it works fine with uhci_hcd as a 1.1 device. On my
Asus desktop machine, it sometimes mounts as a 1.1 device
automatically, other times not, but in no case does the light on the
device blink. The device is a Corsair Flash Voyager 2 GB stick. It
works as a 2.0 device on Mac and Windows (the latter on my Thinkpad,
so it's not hardware). I have kernel-2.6.10-1.766_FC3 and
hotplug-2004_04_01-8.1. When it doesn't mount, it also doesn't appear
in lsusb. I tried this:
echo -n "Y" > /sys/module/usbcore/parameters/old_scheme_first
echo -n "Y" > /sys/module/usbcore/parameters/use_both_schemes
from bug 145273, but no help. They were already set that way.
Created attachment 111844 [details]
/var/log/messages output from "successful" USB 1.1 mount of 2.0 device
When it doesn't work, I get this:
Mar 10 02:15:16 oobleck kernel: usb 1-8: new high speed USB device
using ehci_hcd and address 27
Mar 10 02:15:17 oobleck kernel: usb 1-8: device not accepting address
27, error -71
On the laptop, it cycles through the addresses and repeatedly fails,
about once a second. Both machines have the same packages; both were
fresh FC3 installs in the past month, with all updates.
For the attachment messages, note that despite what it says, this is a
USB 2.0 device and a 2.0 socket.
Created attachment 111845 [details]
lsusb output from a successful mount
Created attachment 111846 [details]
lsusb -v output from a successful mount
Note that these "successful" mounts run at 1.1 speeds, not 2.0 speeds as
expected. But, they do run.
I also have the same behavior on my Sony DRX-500 ULX DVD+-RW drive. Same "not
accepting address" error messages, repeated at intervals of a few seconds with
the address incrementing until it's unplugged. Clearly, a DVD writer is useless
at USB 1.1 speeds.
Both my devices still fail the same way for the rebased kernel,
kernel-2.6.11-1.14_FC3. The memory stick works in USB 2.0 under Windows XP
(couldn't test the DVD writer, the XP machine is at home, but it worked under FC1).
Same lack of USB 2.0 support with kernel-2.6.11-1.27_FC3. Do others have USB
2.0 devices that work?
Same lack of USB 2.0 support with kernel-2.6.11-1.35_FC3. I am curious why this
issue doesn't seem to interest anyone to look at it. Are Keith and I the only
ones with the problem? Do others have USB 2.0 devices that *do* work? Should
I continue to bother posting an update on whether each new kernel fixes the problem?
I am curious as well. Is there a chance this will be fixed in FC4? Is anybody
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
I have since moved to FC4 (kernel build 2.6.12-1.1390) and the problem still
occurs, so I have changed the version field to 'fc4'.
I just tested it again on FC3 with the 2.6.12-1.1372_FC3 kernel. Same behavior.
Kernel messages and some device info are attached. As before, when I did a
'rmmod ehci_hcd', it mounted using uhci_hcd and acted as a USB 1.1 device. I
tested by timing a file transfer, which got about 1 MB/sec.
Created attachment 116933 [details]
/var/log/messages excerpt after boot of new kernel.
The device mounted after I rmmodded ehci_hcd, but acted like a USB 1.1 device
Like bug 145273, I think this is notabug, but I'll let others confirm. All the
ports on my mobo are 2.0, but some are hooked up to front- or back-panel ports
by case cables that, it turns out, are not 2.0-compliant. The result was that
it only worked at 1.1 speeds. The (harder-to-reach) direct-on-the-mobo ports
work fine as 2.0 with the same devices. The behavior is totally consistent for
me, for all 2.0 devices I own. The case is an Antec PerformancePlus 1080AMG,
and Antec is sending new internal cables for free, in case anyone has the same case.
My IBM Thinkpad T40 also exhibits the problem, but under Windows as well. Other
IBM Thinkpads don't have the problem, and I think this one didn't in the past.
On bug 145273, a power issue was mentioned, so it may be a hardware issue. In
any event, since I can get the devices to work on the on-the-mobo ports on my
desktop, it appears not to be a Linux problem. Regarding Comment 6, yes, I
think the ports actually did devolve! I've had some other problems on the same
system board, such as the ethernet controller flaking out and/or being slow to
respond to requests for its ethernet address.
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (188.8.131.52). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
Tested with kernel build 2.6.14-1.1637_FC4 (smp). No joy, the problem still
I also had this problem (error -71 in dmesg output) but disabling legacy USB
support in the BIOS solved it.
This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Closing per previous comment.