Red Hat Bugzilla – Bug 171554
Spurious keyboard repeats in Gnome after upgrade to 2.6.13-1.1532
Last modified: 2015-01-04 17:22:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050927 Fedora/1.0.7-2.1.fc4.nr Firefox/1.0.7
Description of problem:
Since upgrading from 2.6.13-1.1526 to 2.6.13-1.1532, I get random (and long keyboard repeats. The only way to stop this from happening is to turn off the Gnome setting for keybaord repeats. The problem is deeper than this though.
After turning off the keyboard repeats,I tried playing an mp3 and the sound was choppy. This has never happened prior to the kernel update.
This made my think that something was hogging resources to I started Gnome-System-Monitor and strangely enough, every time I moved a window, the CPU graph would just slip across the screen instead of just scrolling left once per second.
It would seem that there is I/O racing issues this kernel.
I downgraded back to 2.6.13-1.1526 and all my problems went away!!!
This is a heads up that something in that kernel is not right.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Get yourself a AUSUS A8N-E Motherboard
2. Upgrade to 2.6.13-1.1532
3. Start typing away in GNOME
This may affect nForce Motherboards,I dont know as this is the only one I could test on.
Actual Results: I/O racing. Bad performance.
Expected Results: No Keyboard repeats and normal priority threads.
I am usinnnnng aaaa MMMMSSSSIIII KKK8N Neo4 and am obbbbviously
experiencing the sammme problem. It has started after the 2.6.13-1.1532 upgrade.
I am using a USB keyboard and have the same isssssues when uuuuuuuusinggggg
eeeeeeither USB or PS2 connectionsssssss.
That makes two (so far) with nvidia chipset motherboards. And I was getting the
same happening with both USB or PS2.
I don't know if it's related or not, but even using the mouse has become
frustrating. Sometimes in order to keep a menu up it is necessary to hold the
button down until over an entry or subentry and then let go in order to make the
selection. Otherwise the menu goes away after you let go of the button.
The gnome mouse double-click adjustment tool seems to work ok.
This problem did not exist before 1532 either.
Yes. I forgot to mention this myself. I too had problems particularly with gnome
panel menus in keeping them open. I had to click and drag to menu items instead
of the normal click and move.
I've seen this issue as well on 2.6.13-1.1526_FC4smp with a USB keyboard using
KDE in the Konsole program. This is on an ABIT AN8 motherboard (nvidia chipset
I own an Asus a8n-e and have the same issue. Downgrading to 2.6.13-1.1526_FC4smp
worked for me. I did some brief testing at runlevel 3 and could not reproduce.
Hows the progress on this job?
It is obvious that some option has been enabled in kernel build 1532 that was
not enabled in 1526. I have also just tried Dave Jones experimental 2.6.14-1633
and the problem still persists.
At a guess, I suspect the following change as the culprit:
* Sun Oct 16 2005 Dave Jones <firstname.lastname@example.org> [2.6.13-1.1530_FC4]
- Reenable change of timesource default.
It is still happening on the 2.6.14-1633 kernel for me. I have to go back to
2.6.13-1526 for it to work properly. I have read on the Fedora list the the
Kernel option noapic will fix this. Still, a workaround is not a permanent solution.
The clock time is messed up as well, it runs so fast that NTP updates can't keep
up. I've gone back to 1526 as well.
Yep, this is happening on RHEL4. I'll start a new bugzilla for that OS.
I just tried 2.6.14-1633 for a second time and it hasn't fixed this issue with
my Asus A8N-E motherboard. I even tried the NOAPIC option to see if that would
help but I had the same result. I have attached my dmesg output for anyone who
Bug 55223 is probaby the same but it says it happens under network load in the
title. I dont think it is bound to network load specifically as I can get things
to happen when the load is minimal. Still is still possibly a duplicate of the
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.
2.6.14-1.1637_FC4 and 2.6.14-1.1637_FC4smp appear to solve the issue on my A8N-E.
I have just installed 2.6.14-1.1637_FC4smp and the issue is still persisting.
The keyboard isn't repeating hallllf aaaas much as it used to. Another good
test is the Gnome Monitor. As I mentioned above: I started Gnome-System-Monitor
and strangely enough, every time I moved a window, the CPU graph would just slip
across the screen instead of just scrolling left once per second. - This iiiis
jjjuuuuussssstttt tttthhhheeeee ssssaaaaaammmeeee aaassssss iiittt
Gavin is correct...sorry for the misleading info. The keyboard repeat issue is
much less apparant, but the real time clock is seriously fubar. Reverting to
2.6.13-1.1526_FC4smp. Closer, but still not right.
Same results here.
My keyboard is not always working on several Abit IC7-G's in latest Fedora Core
kernels. After some roboot it works and after some not. I think it is related to
this bug. I also get error messages about time source.
Still broken on 2.6.14-1.1644_FC4smp
I have also tried 2.6.14-1.1664_FC4smp and I even tried the kernel parameteres
noapic & notsc but the problem still persists.
I thought it was fixed but after an hour and a half the repeats started. So far
the time seems ok, so I have disabled keyboard repeats and will see how the
From what I have found through searching, this is only an issue with the SMP
Have any of the maintainers been able to duplicate this issue? Is there any
information we can provide that would help?
After 6 hours the time stayed in sync, but even with the keyboard repeat
disabled the keys began repeating. I have gone back to 1526 again.
After some googling I have tried using the clock=tsc option with the
2.6.14-1.1644 kernel. I not exactly sure what this does, but after 8 hours I
haven't encountered any repeating keys and the time is staying in synch. I have
now rebooted and am keeping my fingers crossed.
Danny, can you include the output of 'dmesg -s 128000' from both a kernel with
and without that parameter ? (Better yet, save both files, and then do
something like diff -u dmesg-broken dmesg-works
It's odd that clock=tsc helps you, as the change that is mentioned in the
changelog above actually promotes the tsc as a clocksource.
Created attachment 121953 [details]
dmesg with clock=tsc
Created attachment 121954 [details]
dmesg without clock=tsc
Created attachment 121955 [details]
See how they both have "Using tsc for high-res timesource" ?
I'm totally puzzled why that parameter makes any difference for you, as you're
just overriding something to the setting it's already set at.
What is really unusual though is the 'had 0 usecs skew' messages. They should
only be printing out if you have >2 usecs skew, so there could be a more deep
rooted problem here thats the actual cause..
Created attachment 121986 [details]
dmesg of 1526 kernel
The clock=tsc didn't fix things, it just took a lot longer to show up.
I'm attaching two more files: the dmesg from the 1526 kernel, which works fine,
and the diff between it and the 1644.
One difference I see is
-Detected 2210.399 MHz processor.
-Using pmtmr for high-res timesource
+Detected 2210.390 MHz processor.
+Using tsc for high-res timesource
Is there a switch for the new kernel to force the use of pmtmr? I would give
that a try and see if it is the cause.
One thing I notice when the key repeat issue occurs, although not at the same
time, is the rapid alternation of the processor status in the system monitor. I
run two instances of folding at home on this computer, so the processor status
box in the tray is always filled in, and in the System Monitor dialog, both
lines stay at 100%. With the kernels after 1526, periodically each cpu status
goes to 0 and back to 100% for several seconds. When I see this activity it is
usually not long before I get the key repeats.
Created attachment 121987 [details]
diff between 1526 and 1644
timer=pmtmr will set that as the default instead of tsc.
if you boot 1644 with that, does it work ?
timer=pmtmr didn't change from tsc, but clock=pmtmr did. I will report back if
the key repeats start again, and if they don't after 24 hours I will post the
dmesg and diff between 1644 with tsc and with pmtmr
Thanks for your efforts.
I am trying out 2.6.14-1644 with the clock=pmtmr kernel option and so far it
seems to be working. I will report back later with a more definitive answer.
DMESG is reporting:
CPU#0 had 0 usecs TSC skew, fixed it up.
CPU#1 had 0 usecs TSC skew, fixed it up.
...Which is a concern to DaveJ still.
Created attachment 122057 [details]
1644 kernel with clock=pmtmr
It's over 24 hours now and I've yet to encounter a problem. This is the dmesg
for the 1644 kernel with clock=pmtmr
I will follow with the diff file of this with the 1644 kernel using clock=tsc
Created attachment 122058 [details]
diff of 1644 with clock=pmtmr and no option
This is my home computer. If there is anything I can do to help identify or
resolve this issue, please let me know.
I have been running for well over 24 hours with the clock=pmtmr option and I
have not had any problems at all with all the scenarios I use (read much ealier
in the bug) to test.
My DMESG read very much the same as Dannys.
It looks like there may be afix in the near future.
Over 22 hrs now on 2.6.14-1.1653_FC4smp without a single problem. In fact, although
its probably just in my mind, there seems to be a noticeable performance improvement.
I've ran it for a while too:
[me@work foobar]$ uname -a
Linux work 2.6.14-1.1644_FC4smp #1 SMP Sun Nov 27 03:39:31 EST 2005 i686 athlon
[me@work foobar]$ uptime
08:58:24 up 2 days, 22:44, 9 users, load average: 0.33, 0.14, 0.05
[me@work foobar]$ cat /proc/cmdline
ro root=LABEL=/ rhgb quiet clock=pmtmr
err nm :-( Getting update now...
clock=pmtmr shouldn't be needed any more.
I have been running 2.6.14-1.1653_FC4smp for over 24 hours without clock=pmtmr
and the problems have gone.
Previously, the clock=pmtmr did fix the issue so it looks like the recent
changes in the 1653 kernel have fixed this without needing the extra kernel option.