Bug 173481 - USB performance for kernel-smp-2.6.14-1.1637_FC4 is terrible (as tested with USB mice, keyboards, and USB key drive).
USB performance for kernel-smp-2.6.14-1.1637_FC4 is terrible (as tested with ...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-11-17 09:40 EST by Paul S. Graham
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-04 08:52:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul S. Graham 2005-11-17 09:40:58 EST
Description of problem:

USB performance for kernel-smp-2.6.14-1.1637_FC4 terrible

Version-Release number of selected component (if applicable):

How reproducible:
Very reproducible (unfortunately).

Steps to Reproduce:
Case 1. Use USB mouse/keyboard.
Case 2. Use USB key drive (Lexar USB 1GB  drive: JDX1GB-00-500).
Actual results:
Case 1. With USB keyboards or mice, movements or keystrokes are only recorded
intermittently.  This was tried with a variety of USB mice.  With PS/2 keyboard,
no keystrokes were lost (by contrast)

Case 2. When using USB key drive (Lexar USB 1GB  drive: JDX1GB-00-500), getting
a directory listing using Nautilus took minutes.

Expected results:
Case 1. Using the uniprocessor kernel (kernel-2.6.14-1.1637), USB mice and
keyboards operate smoothly (no missed keystrokes and cursor movement is very

Case 2. Using the uniprocessor kernel (kernel-2.6.14-1.1637), the directory
listing of the USB key drive was almost instantaneous (a few seconds).

Additional info:
Motherboard: Tyan Tiger 133 (S1834) (VIA Apollo Pro 133A Chipset (VT82C694X &
Processors: 2 Intel Pentium III 750 MHz, Slot 1
USB key drive: Lexar USB 1GB drive (JDX1GB-00-500)
Mice: Logitech Marble Mouse USB (T-BB14), Compaq Wireless Mouse (MSR0238T)
Keyboard: Compaq Wireless USB Keyboard (KBR0108)

Other Notes: The performance of USB under kernel-smp-2.6.13-1.1532_FC4 was
better but not as good as the uniprocessor kernel.
Comment 1 Pete Zaitcev 2005-11-26 22:44:13 EST
This is one of two things: HC is broken, or SMM BIOS messes with the
hardware behind our backs.

Please try usb-handoff option in grub.conf command line (where root=X is).
Also (separately), try to disable everything that resembles "USB Legacy
Support" or "Compatibility" or whatever
Comment 2 Paul S. Graham 2005-12-08 09:39:01 EST
I tried both usb-handoff in grub.conf and disabling/altering things in the BIOS.
 No luck yet.

Here is the entry I used in grub.conf:

title Fedora Core (2.6.14-1.1637_FC4smp)
        root (hd0,0)
        kernel /vmlinuz-2.6.14-1.1637_FC4smp ro root=/dev/VolGroup00/root
usb-handoff rhgb quiet
        initrd /initrd-2.6.14-1.1637_FC4smp.img

As for the BIOS, I actually didn't find "USB Legacy Support" or "USB
Compatibility".  I did turn off "USB Keyboard Support", but it had no affect on
the problem.  I also disabled ACPI and tried MP=1.1 to see if that would have an
effect---no luck.

Any additional suggestions?


Comment 3 Pete Zaitcev 2005-12-08 14:03:09 EST
No ideas at present time. We may be sure that HC is all right though, I did
not read the report closely enough. All signs point to a rude SMM BIOS.
I don't know what made it act up in recent kernels...
Comment 4 Nicholas Miell 2005-12-12 17:11:22 EST
I'm seeing something similar (jerky/stuttery mouse movement, terrible gamepad
control) on a MSI Master2-FAR (VIA K8T800 chipset) with the AMD64
kernel-smp-2.6.14-1.1644_FC4. It doesn't happen immediately (or always), but
once it starts, it'll occur if I plug the mouse/gamepad into any of the USB
controllers and it survives a warm reboot.

USB Legacy is disabled (iirc, I'm going to reboot, check that, and then try
usb-handoff after I finish this comment).
Comment 5 Nicholas Miell 2005-12-17 22:13:21 EST
I'm still seeing this with 1653, but I've found a workaround that doesn't
require a reboot -- forcing the UHCI driver to reinit the host controller (by
unbinding and then rebinding it to the PCI devices) seems to clear it up.

For the unitiated, unbinding/rebinding can be accomplished by something similar
to the following. Obviously, you really want to script this if you have a USB
keyboard. I also do the EHCI controller for good measure.

# cd /sys/bus/pci/drivers/uhci_hcd
# ls
0000:00:10.0  0000:00:10.1  0000:00:10.2  bind  new_id  unbind
# echo -n "0000:00:10.0" > unbind
# echo -n "0000:00:10.1" > unbind
# echo -n "0000:00:10.2" > unbind
# echo -n "0000:00:10.0" > bind
# echo -n "0000:00:10.1" > bind
# echo -n "0000:00:10.2" > bind
# cd /sys/bus/pci/drivers/ehci_hcd
# ls
0000:00:10.4  bind  new_id  unbind
# echo "0000:00:10.4" > unbind
# echo "0000:00:10.4" > bind
Comment 6 Nicholas Miell 2006-01-13 16:15:16 EST
2.6.14-1.1656_FC4smp is still doing this, in case you were wondering. :)

My handy script automating the workaround. --


if [ -d "$UHCI_HCD" ]; then
        UHCI_DRIVERS=$(find $UHCI_HCD -type l -printf "%f\n");

if [ -d "$OHCI_HCD" ]; then
        OHCI_DRIVERS=$(find $OHCI_HCD -type l -printf "%f\n");

if [ -d "$EHCI_HCD" ]; then
        EHCI_DRIVERS=$(find $EHCI_HCD -type l -printf "%f\n");

# unbind them all

for f in $UHCI_DRIVERS; do
        echo -n "$f" > $UHCI_HCD/unbind;

for f in $OHCI_DRIVERS; do
        echo -n "$f" > $OHCI_HCD/unbind;

for f in $EHCI_DRIVERS; do
        echo -n "$f" > $EHCI_HCD/unbind;

# rebind them
for f in $UHCI_DRIVERS; do
        echo -n "$f" > $UHCI_HCD/bind;
        sleep 1

for f in $OHCI_DRIVERS; do
        echo -n "$f" > $OHCI_HCD/bind;
        sleep 1

for f in $EHCI_DRIVERS; do
        echo -n "$f" > $EHCI_HCD/bind;
        sleep 1
Comment 7 Dave Jones 2006-02-03 00:48:44 EST
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.

Thank you.
Comment 8 Pete Zaitcev 2006-03-29 14:33:51 EST
Actually, while the update above was scripted, I am indeed interested if
current kernels fix anything. Don't forget to mention exact version tested,
do not use word "current". Thanks...
Comment 9 John Thacker 2006-05-04 08:52:07 EDT
Closing per previous comment.

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