Bug 171554 - Spurious keyboard repeats in Gnome after upgrade to 2.6.13-1.1532
Spurious keyboard repeats in Gnome after upgrade to 2.6.13-1.1532
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-23 00:07 EDT by Gavin Graham
Modified: 2015-01-04 17:22 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-17 02:05:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg with clock=tsc (21.24 KB, text/plain)
2005-12-06 20:44 EST, Danny
no flags Details
dmesg without clock=tsc (20.91 KB, text/plain)
2005-12-06 20:45 EST, Danny
no flags Details
diff (4.42 KB, text/plain)
2005-12-06 20:45 EST, Danny
no flags Details
dmesg of 1526 kernel (20.79 KB, text/plain)
2005-12-07 11:29 EST, Danny
no flags Details
diff between 1526 and 1644 (11.09 KB, text/plain)
2005-12-07 11:30 EST, Danny
no flags Details
1644 kernel with clock=pmtmr (20.92 KB, text/plain)
2005-12-08 22:10 EST, Danny
no flags Details
diff of 1644 with clock=pmtmr and no option (4.16 KB, text/plain)
2005-12-08 22:13 EST, Danny
no flags Details

  None (edit)
Description Gavin Graham 2005-10-23 00:07:30 EDT
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):
Kernel-2.6.13-1.1532

How reproducible:
Always

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.

Additional info:
Comment 1 Danny 2005-10-23 10:59:18 EDT
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.
Comment 2 Gavin Graham 2005-10-23 15:49:39 EDT
That makes two (so far) with nvidia chipset motherboards. And I was getting the
same happening with both USB or PS2.
Comment 3 Danny 2005-10-23 16:00:05 EDT
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.
Comment 4 Gavin Graham 2005-10-23 16:22:45 EDT
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.
Comment 5 David 2005-10-24 17:54:29 EDT
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
as well)
Comment 6 Sean Hawkins 2005-10-26 20:18:34 EDT
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.
Comment 7 Gavin Graham 2005-10-29 17:20:19 EDT
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 <davej@redhat.com> [2.6.13-1.1530_FC4]
- Reenable change of timesource default.
Comment 8 Gavin Graham 2005-10-31 17:10:50 EST
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.
Comment 9 Danny 2005-10-31 17:20:39 EST
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.
Comment 10 Brian Smith 2005-11-01 10:01:36 EST
Yep, this is happening on RHEL4.  I'll start a new bugzilla for that OS.
Comment 11 Gavin Graham 2005-11-02 02:51:24 EST
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
is interested.
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
bug though.
Comment 12 Dave Jones 2005-11-10 14:23:08 EST
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.

Thank you.
Comment 13 Sean Hawkins 2005-11-11 13:47:18 EST
2.6.14-1.1637_FC4 and 2.6.14-1.1637_FC4smp appear to solve the issue on my A8N-E.
Comment 14 Gavin Graham 2005-11-11 14:59:08 EST
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
ssssttttiiiilllllllllll       
hhhhhhhaaaaaaapppppppppppppppppppeeeeeeeeennnnnnnnniiiiiiiinnnnngggggg     
jjjuuuuussssstttt    tttthhhheeeee     ssssaaaaaammmeeee    aaassssss    iiittt
wwwwwwaaaaaaaassss  bbbbeeeeffffooorrrrrrrrrrrrrrrrrrre.


Comment 15 Sean Hawkins 2005-11-12 10:16:28 EST
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.
Comment 16 Danny 2005-11-19 13:46:11 EST
Same results here.
Comment 17 Marek Greško 2005-11-28 06:19:00 EST
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.
Comment 18 David 2005-11-29 16:39:30 EST
Still broken on 2.6.14-1.1644_FC4smp
Comment 19 Gavin Graham 2005-11-29 17:19:50 EST
I have also tried 2.6.14-1.1664_FC4smp and I even tried the kernel parameteres
noapic & notsc but the problem still persists.
Comment 20 Danny 2005-11-29 17:23:57 EST
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
clock behaves.

From what I have found through searching, this is only an issue with the SMP
kernel. 

Have any of the maintainers been able to duplicate this issue? Is there any
information we can provide that would help?
Comment 21 Danny 2005-11-29 22:22:18 EST
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.
Comment 22 Danny 2005-12-06 18:38:41 EST
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.
Comment 23 Dave Jones 2005-12-06 18:55:26 EST
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.
Comment 24 Danny 2005-12-06 20:44:04 EST
Created attachment 121953 [details]
dmesg with clock=tsc
Comment 25 Danny 2005-12-06 20:45:02 EST
Created attachment 121954 [details]
dmesg without clock=tsc
Comment 26 Danny 2005-12-06 20:45:53 EST
Created attachment 121955 [details]
diff
Comment 27 Dave Jones 2005-12-06 23:12:10 EST
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..
Comment 28 Danny 2005-12-07 11:29:20 EST
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.
Comment 29 Danny 2005-12-07 11:30:44 EST
Created attachment 121987 [details]
diff between 1526 and 1644
Comment 30 Dave Jones 2005-12-07 15:09:44 EST
timer=pmtmr will set that as the default instead of tsc.
if you boot 1644 with that, does it work ?
Comment 31 Danny 2005-12-07 15:56:50 EST
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.
Comment 32 Gavin Graham 2005-12-07 17:16:05 EST
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.
Comment 33 Danny 2005-12-08 22:10:06 EST
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
Comment 34 Danny 2005-12-08 22:13:09 EST
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.
Comment 35 Gavin Graham 2005-12-09 15:13:01 EST
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.
Comment 36 Danny 2005-12-13 17:43:25 EST
It looks like there may be afix in the near future.

http://forums.fedoraforum.org/showthread.php?t=88295
Comment 37 Danny 2005-12-15 15:00:20 EST
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.
Comment 38 David 2005-12-16 10:55:29 EST
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
i386 GNU/Linux
[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
Comment 39 David 2005-12-16 10:57:18 EST
err nm :-( Getting update now...
Comment 40 Dave Jones 2005-12-16 15:52:50 EST
clock=pmtmr  shouldn't be needed any more.
Comment 41 Gavin Graham 2005-12-16 16:32:43 EST
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.

 

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