Bug 172199 - Spurious keyboard repeats and clock is fast
Spurious keyboard repeats and clock is fast
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Brian Maly
Brian Brock
Depends On:
Blocks: 181409
  Show dependency treegraph
Reported: 2005-11-01 10:10 EST by Brian Smith
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

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

Attachments (Terms of Use)
patch to reorder timesource selection on x86 (391 bytes, patch)
2006-02-28 15:32 EST, Brian Maly
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0575 normal SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 4 Update 4 2006-08-10 00:00:00 EDT

  None (edit)
Description Brian Smith 2005-11-01 10:10:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 Red Hat/1.0.7-1.4.1 Firefox/1.0.7

Description of problem:
This is the same as bug 171554, except for RHEL.

This machine is an Athlon 4400+ X2, with an MSI K8N Neo4 motherboard.  Though it's is x86_64 I am running the 32 bit OS.

Unless key repeat is turned off, it becomes impossible to type.  Setting repeat rate does nothing.  Doesn't matter if USB or PS/2 keyboard.

Also, the clock gains about 10 minutes an hour, so fast that ntpd can't keep up.  Thus I am forced to do ntpdate every 5 minutes.

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

How reproducible:

Steps to Reproduce:
1. Start typing or sit and wait and watch time fly.

Additional info:
Comment 1 Brian Smith 2005-11-09 14:54:03 EST
Indeed this is also similar to bug 55223.  Booting with the non-SMP kernel seems
to fix it.
Comment 2 Brian Maly 2005-11-09 15:02:50 EST
Is your system using powernow-k8? It should be in dmesg if its enabled. Powernow
on SMP systems is known to cause some timekeeping issues.

Also, what timesource is your system using? HPET, PIT, PMTIMER?
Do a "dmesg | grep time.c" to be sure.
Comment 3 Brian Smith 2005-11-09 15:37:00 EST
Hmm...neither of those dmesg greps returns anything for me.  Any other ways to
check the powernow?

dmesg | grep -i time returns:

ACPI: PM-Timer IO Port: 0x4008
Using tsc for high-res timesource
per-CPU timeslice cutoff: 2926.76 usecs.
task migration cache decay timeout: 3 msecs.
..TIMER: vector=0x31 pin1=0 pin2=-1
Real Time Clock Driver v1.12
PCI: Setting latency timer of device 0000:00:07.0 to 64
Comment 4 Brian Maly 2005-11-09 15:51:06 EST
Its using TSC for timekeeping, which is known to cause timekeeping issues on
some systems.

Try booting with "notsc" appended to the boot line parameters in grub.
The system should use another timesource. It may likely fix the problem.

As for powernow, when the system first boots, it prints out a bunch of info
about powernow. If this is absent at boot, powernow isnt loaded. Loglevel must
be changed in /etc/syslogd.conf to report KERN_INFO. Otherwise you wont see the
powernow stuff show up in dmesg.

Also, your sysfs should have a bunch of stuff like this if powernow is enabled:
Comment 5 Brian Smith 2005-11-09 16:07:07 EST
Ok /sys/devices/system/cpu/cpu0 has nothing in it.

/etc/syslog.conf has:
kern.*                                                  @loghost
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

so I think that should get reported then.

I'm rebooting with notsc on the kernel line, and I'll see how it goes over the
Comment 6 Brian Smith 2005-11-15 13:19:51 EST
Rebooting with notsc did not work:

Kernel command line: ro root=LABEL=/1 rhgb quiet notsc
notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.
Using tsc for high-res timesource

I am going to give noapic a try, as in bug 55223.

Comment 7 Brian Smith 2005-11-18 14:24:20 EST
noapic is still broken.
Comment 8 beepx1 2005-11-26 13:19:11 EST
(In reply to comment #6)
> Rebooting with notsc did not work:
> Kernel command line: ro root=LABEL=/1 rhgb quiet notsc
> notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.
> Using tsc for high-res timesource
> I am going to give noapic a try, as in bug 55223.

Does this mean you have to recompile the kernel to accept the "notsc"?
Comment 9 Brian Smith 2005-12-13 14:04:20 EST
As in bug 171554, clock=pmtmr has this machine running now with an SMP kernel
for 24 hours, no problem.
Comment 10 Brian Smith 2006-01-23 10:51:23 EST
2.6.9-22.0.2.EL doesn't fix it.  Though it seems the new kernel for FC4 fixes it
on that OS.
Comment 11 Mark Frankenfield 2006-02-28 13:17:19 EST
This would seem to be the same as bug 5105 on the bugzilla.kernel.org 

I can see if kernel-smp-2.6.9-29.EL.x86_64 has this fix included.
Comment 12 Brian Maly 2006-02-28 15:32:02 EST
Created attachment 125418 [details]
patch to reorder timesource selection on x86

On AMD systems that are using powernow-k8, the TSC cannot be used as a
timesource being its quite problematic. Problems range from spurious keyboard
repeats to timekeeping issues if TSC is used with powernow-k8. This patch gets
us inline with upstream (as of linux- anyway), and additionally gets
timesource ordering on x86 inline with timesource ordering on x86_64.
Timesource selction is now ordered as follows for x86: (Cyclone, HPET, PMTimer,
TSC, PIT), and for x86_64: (HPET, PMTimer, TSC, PIT). 

patch posted 2/28/2006
Comment 13 Jason Baron 2006-04-19 10:51:58 EDT
committed in stream U4 build 34.19. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/ However, there is a *serious* slab
corruption issue with this kernel, and thus it should not be released to
customers under any circumstances. I'll update this bug when the kernel is
stable again.
Comment 14 Jason Baron 2006-04-19 15:54:22 EDT
We've identified the corruption as specfic to x86-64 smp kernel builds 34.16 and
34.17. All other builds are safe for consumption.
Comment 17 Red Hat Bugzilla 2006-08-10 17:29:13 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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