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:
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 as well)
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 <davej> [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 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.
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.
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 ssssttttiiiilllllllllll hhhhhhhaaaaaaapppppppppppppppppppeeeeeeeeennnnnnnnniiiiiiiinnnnngggggg jjjuuuuussssstttt tttthhhheeeee ssssaaaaaammmeeee aaassssss iiittt wwwwwwaaaaaaaassss bbbbeeeeffffooorrrrrrrrrrrrrrrrrrre.
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 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?
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] diff
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. http://forums.fedoraforum.org/showthread.php?t=88295
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 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
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.