Bug 127411 - System clock runs too fast or too slow
System clock runs too fast or too slow
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks: FC3Target FC4Target
  Show dependency treegraph
 
Reported: 2004-07-07 16:47 EDT by Robert Scheck
Modified: 2015-01-04 17:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-19 23:02:00 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)
Outpu from `lspci -vvv` (4.21 KB, text/plain)
2004-07-07 16:48 EDT, Robert Scheck
no flags Details

  None (edit)
Description Robert Scheck 2004-07-07 16:47:05 EDT
Description of problem:
At a Asus P5A mainboard using a AMD K6-2 450 MHz processor, the 
kernels from Fedora Core 2 bring up the problem, that the system 
clock runs either too fast (more than twice times to fast using 
2.6.5-1.358) and too slow (using 2.6.6-1.435.2.3).

Version-Release number of selected component (if applicable):
kernel-2.6.5-1.358.i586
kernel-2.6.6-1.435.2.3.i586

How reproducible & Steps to Reproduce:
See above.
  
Actual results:
Well, the system clock is either too slow or too fast, but has no 
normal speed...

Expected results:
Working system clock with normal speed ;-)

Additional info:
Attaching you a lspci -vvv for further information.
Comment 1 Robert Scheck 2004-07-07 16:48:13 EDT
Created attachment 101693 [details]
Outpu from `lspci -vvv`
Comment 2 Barry K. Nathan 2004-07-14 04:31:30 EDT
If you try a kernel from one of the following sources, does the
problem still occur?

+ rawhide (a.k.a. FC-devel)
+ FC 3 test 1
+ http://people.redhat.com/arjanv/2.6/
Comment 3 Robert Scheck 2004-07-15 10:38:44 EDT
Sorry Barry, but the latest available Kernel 2.6 for Fedora Core 
didn't solve it:

For the test, kernel-2.6.7-1.488.i586.rpm was used (that rpm is in 
Fedora Development and Arjan's public directory; they are synchron at 
current).

The result, timed with a stopwatch: ~10 system seconds at the system 
are ~40 seconds realtime! :-(
Comment 4 Dick Bonnema 2004-09-14 09:03:03 EDT
I installed kernel 2.6.8 , same result
Comment 5 Jay Phelps 2004-09-22 17:57:38 EDT
I'm running 2.6.8-1.521 with the result of a significantly slow clock.
 This is not an issue with a stock 2.6.8.1 kernel.
Comment 6 Jay Phelps 2004-09-23 14:34:04 EDT
Excuse me, I was mistaken.  I had an opprotunity to retest this today
and it is occuring on a FC2 distribution with a 2.6.8.1 kernel from
kernel.org using the same options as my custom FC2 kernel.  This is
occuring at the same ration as mentioned above: aprox 1:4
Comment 7 Jay Phelps 2004-09-29 18:04:52 EDT
The system clock will keep correct time if my CPU is at 100%
utilization.  If I execute the following script to push my CPU to 100%
and keep it there the system clock keeps time correctly while it is
running.

#!/bin/bash
while [ 1 ]; do
   TEMP=0
done

Not sure how to track this down with this clue however.
Comment 8 Arjan van de Ven 2004-09-30 01:28:10 EDT
that's a useful observation; linux will call into the bios when idle
(to let the bios do power saving) or will power save the cpu itself,
at least by default.

If you add "idle=poll" at the kernel commandline (use the "a" key in
grub), does this get "fixed" too ?
Comment 9 Jay Phelps 2004-09-30 13:30:27 EDT
Specifying idle=poll had no impact on kernel-2.6.8-1.521custom

I am using ACPI support and cpufreqd with this kernel but performed my
testing just now on AC power.
Comment 10 Eric Andresen 2004-11-16 00:07:03 EST
I'm seeing similar behavior on FC3 with an hp pavillion xt155 (1.2GHz
Celeron) laptop. The clock is running much too slow, and can't keep
the time without the assistance of ntp (which only helps so much).

Kernel: 2.6.9-1.667
Comment 11 Eric Andresen 2004-11-16 00:12:12 EST
More information gleamed from a thread on fedoraforum.org: only the
software clock is wrong; the hardware clock is correctly incrementing.

Forumn thread:
http://www.fedoraforum.org/forum/showthread.php?s=b0bdf81d479fa56d56c8553af0f0a5f4&t=19788
Comment 12 Otto 2004-12-19 11:43:39 EST
Same Problem on:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 8
model name      : AMD-K6(tm) 3D processor
stepping        : 12
cpu MHz         : 350.714
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow 
 
Comment 13 Dave Jones 2005-04-16 01:55:06 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.
Comment 14 Eric Andresen 2005-04-16 11:34:20 EDT
As per comment #10, I am seeing this on FC3. I cannot reopen the bug, nor change
the version, due to being an unprivileged user.
Comment 15 Robert Scheck 2005-04-16 11:38:08 EDT
Thank you Eric for posting this information; I've got no i586 computer any more
at home - reopening and re-assigning.
Comment 16 Dave Jones 2005-04-16 15:26:29 EDT
586 era computers had very flaky ACPI support, we probably shouldn't even bother
trying it and hoping it'll work (unless the user passes acpi=force).

Does booting with acpi=off make this problem stop ?
(They should have [hopefully working] APM support)
Comment 17 Eric Andresen 2005-04-16 18:09:54 EDT
Running FC1 with a 2.4 kernel, no problems existed. Using FC3, my software clock
runs 1 second for every 3 seconds realtime.

This is on a P4-based Celeron laptop, with the following /proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Mobile Intel(R) Celeron(R) CPU 1.80GHz
stepping        : 7
cpu MHz         : 1794.704
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips        : 3530.75


There is no APM support for this system; acpi is the only route to handle any
power management at all. As far as I'm aware, this CPU is actually of the i686
class, not i586.

For the mean time, I've been running a simple script to keep my software clock
accurate:
#!/bin/sh
while true; do sleep 1; hwclock --hctosys; done

which works because the hardware clock is accurate, only the system clock is
lagging.
Comment 18 Ewin Barnett 2005-04-22 17:34:34 EDT
I am running Windoze XP on a Dell Insprion 8600 laptop so I can run FC3 under
VMware.  The hardware clock on under Windoze is just fine, as it was while
running RH9 under VMware.  

The software clock on FC3 runs at about 1/6 the correct rate.

In testing, I set the adjtimex adjustments to the max and this is the output of
--compare:

root@VMFC3 eb]# /sbin/adjtimex --compare=20 --interval 2
                                           --- current ---    -- suggested --
cmos time     system-cmos       2nd diff    tick      freq     tick      freq
1114204694     -222.042326    -222.042326   11000   6553600
1114204704     -230.823175      -8.780849   11000   6553600
1114204715     -240.615795      -9.792620   11000   6553600    59964    643098
1114204726     -250.408407      -9.792612   11000   6553600    59964    385286
1114204737     -260.200979      -9.792573   11000   6553600    59964   -895960
1114204747     -268.993345      -8.792365   11000   6553600    54963  -1139712
1114204758     -278.785961      -9.792617   11000   6553600    59964    549348
1114204769     -288.578534      -9.792573   11000   6553600    59964   -895964

I run yum and apt-get update every few days, so the FC3 is as uptodate as I can
make it.

Any suggestions?

-- Ewin
Comment 19 Robert Scheck 2005-05-29 09:18:44 EDT
Is someone of you able to reproduce this problem with Fedora Core 4 test 1-3 or 
even with Rawhide?
Comment 20 Pete 2005-06-29 15:16:44 EDT
I am also facing similar problem.
I am having an old server with Linux 8 Kernel 2.4.18 and system clock is kind 
of stuck. I am running it on HP Netserver LT6000r machine. It goes backward 
and forward very repidly however BIOS time ( hwclock) is correct.
What could have happened ? Any comments ? 

pratul@hotmail.com
Comment 21 Dave Jones 2005-07-15 16:22:48 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 22 stohn 2005-07-19 17:48:17 EDT
Dell Latitude D610 >> Fedora Core 4  >> Latest updates

System and hardware clock run at about the same rate, which is about 5 seconds
over 60 minutes faster than real time.

The laptop constantly runs setiathome, so the CPU is constantly at 100%.

Currently running ntpdate as a cron job to keep proper time.
Comment 23 Robert Scheck 2005-07-23 12:14:24 EDT
Thank you, re-assigning for Fedora Core 4
Comment 24 David J. Rose 2005-08-22 13:13:43 EDT
I am having this problem as well, though the clock is running twice as fast as
it should.  1 minute system time is 30 seconds real time.  My Hardware however,
is not an i586.  I am running an Athlon64 on an MSI 7145 motherboard.  I have
read on some posts dealing with older kernel versions that simply recompiling
the kernel to a newer version can fix this issue, but alas, that is not the case
this time.  I recieve this issue with the stock FC4 x86_64 Kernel from the
install DVD (2.6.11-1.1369_FC4), and from the 2.6.12.5 kernel I compiled myself.
Any information you might want about kernel configs or system configs I am
willing to provide as I would like to try to get this issue resolved.  Thanks.
Comment 25 Jochen Wiedmann 2005-08-23 07:38:44 EDT
Problem still present on FC4 kernel 2.6.12-1.1398_FC4smp. I have tried to build
a custom kernel with HZ=100 in asm-i386/param.h (as suggested by the VMWare
knowledge base), but that didn't solve anything.
Comment 26 Dave Jones 2005-09-30 02:59:10 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 27 Wei Wei 2005-10-12 23:22:21 EDT
I had the same problem (system clock way too fast) with above
kernel(2.6.13-1.1526_FC4) upgraded. AMD Athlon 64bit 3400+.

regards!

-ww
Comment 28 Stefan Hof 2005-10-14 02:46:32 EDT
I Have the same problem (system clock way too fast) with above
kernel(2.6.13-1.1526_FC4) upgraded. AMD AthlonM 64bit 3700+.

see also Bug Nr. 170006

best regards

sh
Comment 29 Stefan Hof 2005-10-14 02:48:17 EDT
I Have the same problem (system clock way too fast) with above
kernel(2.6.13-1.1526_FC4) upgraded. AMD AthlonM 64bit 3700+.

see also Bug Nr. 170006

best regards

sh
Comment 30 Ahmon Dancy 2005-10-14 15:47:02 EDT
"Me too".

2.6.13-1.1526_FC4
AMD Athlon(tm) 64 Processor 3200+"

System time seems to run about twice as fast as real time.  i.e. "sleep 10"
takes 5 seconds.

Comment 31 Ahmon Dancy 2005-10-14 16:18:07 EDT
Additional information in case it matters.
Motherboard: RS480M2-IL (part number MSI-7093)

Upgrading the BIOS to the latest made no difference

Someone else mentioned that they're using an MSI mobo as well.
Comment 32 Ahmon Dancy 2005-10-16 00:41:08 EDT
Booting with kernel command line parameter no_timer_check=0 fixes the problem.
Comment 33 David J. Rose 2005-11-03 13:54:32 EST
If your Motherboard as a built-in ATI XP chip then the bug is in fact due to the
motherboard having two timer pins which gets handled wrong by the APIC portion
of the kernel.  This shouldn't be a problem with the new 2.6.14 kernel release,
as the patch (see bug nr. 152170 ) to fix this issue appears to have been
included in the kernel.  I have not tested this kernel yet, but plan on doing so
within the week.

regards,
djr
Comment 34 Dave Jones 2005-11-10 15:04:55 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 35 Ahmon Dancy 2005-12-19 16:54:28 EST
I just tested on the 1653 build and the clock appears to be working properly now.
Comment 36 Ahmon Dancy 2006-03-02 14:31:39 EST
Update:  After running fine on an 1831 kernel for a while, the clock problem
seems to have reoccurred.  The clock is now running at double speed.  The
following kernel message was logged around the time that I noticed the clock
going nuts:

Losing some ticks... checking if CPU frequency changed.

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