Red Hat Bugzilla – Bug 110405
usb keyboard locks up randomly
Last modified: 2007-11-30 17:10:33 EST
Description of problem:
I have a Microsoft Natural Pro keyboard and it randomly freezes up
when I'm typing. It will continue to print whatever letter I was
hitting when it froze, and typically all of the lights (num, caps,
scroll) come on. It usually regains its senses when I unplug it, plug
it back in and type something. Sometimes when it freezes the lights go
on and rather that simply repeating a character it shuts off certain
keys like alt. It is quite annoying. It may or may not be related to
Bug 64068, and it almost certainly is related to this:
which tracks the bug in the 2.6-test series of kernels. I'm suspecting
some part of the USB system was backported from the 2.6-test series
into the 2.4.22 kernel that Fedora Runs.
The most bizzare thing was that this system was a RH9 system, which I
upgraded to FC1, and never saw the bug. Then, for various reasons, I
did a clean install of FC1 and the bug showed up. I swapped for an
identical keyboard and the bug persists. I did another clean install
of FC1 and I still have the bug.
Version-Release number of selected component (if applicable):
Can the problem be reproduced this in text mode (Ctrl-Alt-F1)?
Yes, problem can be reproduced in text mode. It gets reset by
unplugging and plugging back in the keyboard, as it does in X. Problem
persists in kernel 2.4.22-1.2129.nptl.athlon.
Thanks heavens, text mode says we're in business.
Please do this: get it to die, replug, if it resets ok and
the box survives, run "dmesg > /tmp/dmesg.out" and attach
dmesg.out to the bug (but do not drop into comments box).
Created attachment 96364 [details]
output of dmesg after keyboard spaz and replug
Ok, I attached the output of dmesg.
Created attachment 97295 [details]
verbose usb kernel messages during freeze/replug
I recomplied the kernel to enable more verbose USB debugging output, then I
waited for the keyboard to freeze, and after replugging it, I saved the kernel
messages. Said messages have been attached.
Problem still exists with FC2 (kernel-2.6.5-1.358). I have
demonstrated it now using two keyboards, and 2 motherboards. They
keyboards are identical (Microsoft Natuarl Pro) but the mother boards
are different. One is an Asus A7V600, and the other is an MSI
KT6V-LSR. They are both based on the VIA KT600 chipset, and probably
have the same USB controller. Both keyboards operate normally when
plugged into a machine based on the KT400 chipset.
Created attachment 101231 [details]
kernel log for keyboard error and replug
I built the newest kernel (2.6.6-1.435) using CONFIG_USB_DEBUG and added:
to hid-core.c, hid-input.c, and usbkbd.c. It seems like every thing
rolls along fine until the all the keyboard lights turn on and the
keys go funny, and I get these kernel messages, until I replug:
Jun 17 17:59:09 lazlo kernel: usb 2-1.1: control timeout on ep0in
Jun 17 17:59:14 lazlo kernel: usb 2-1.1: control timeout on ep0in
I've attached the whole kernel log in Comment #7.
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/
Even though this bug was marked FC1, it still exists in the latest FC2
kernels, and therefore doesn't deserve being closed with a WONTFIX and
swept off to fedora legacy. However, if you insist, I can always open
another bug that targets FC2 (and possibly FC3-test as well).
Well, it's not as if David's script can read minds and know if
a bug against FC1 can be applicable to FC2... :-)
Aaron, I see you retargeted the bug already, so just reopen it then.
Evidently this behavior is caused by having gpilotd running. It can't
handle the poling of the USB that gpilotd does. There is some
concensus that this is a hardware flaw rather than a software bug.
Eitherway, its a dup.
*** This bug has been marked as a duplicate of 128602 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.