This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 171219 - Time of day runs much quicker than real time, even when synced to ntp server.
Time of day runs much quicker than real time, even when synced to ntp server.
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
http://bugzilla.kernel.org/show_bug.c...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-19 11:28 EDT by a.purkiss
Modified: 2015-01-04 17:22 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-24 18:06:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
A graph showing the correction amount for each 5 minute period (23.57 KB, image/png)
2005-11-09 20:06 EST, Anssi Johansson
no flags Details

  None (edit)
Description a.purkiss 2005-10-19 11:28:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux x86_64; en) Opera 8.5

Description of problem:
The system clock runs at an accelerated rate, several minutes being gained per 
hour. When synced with an ntp server the system seems for stable for a while, 
but the problem will reoccur. Investiagation of the problem on the web shows 
that adding the kernel boot parameters 

no_timer_check=0 

and / or 

noapic

should stop the problem occuring, but this is not the case. No CPU overclocking 
or throttling is enable in the bios.

The noapic setting did deal with a related symptom, this being multiple 
characters appearing for each key press (apparently a symptom of the same 
problem)


Version-Release number of selected component (if applicable):
kernel-2.6.13-1.1526_FC4smp

How reproducible:
Always

Steps to Reproduce:
1. Boot machine
2. Watch time or /var/log/messages
3.
  

Actual Results:  Time runs fast.

Expected Results:  Time is stable!

Additional info:

The following error message appears in /var/log/messages
Oct 19 13:55:21 ottawa kernel: warning: many lost ticks.
Oct 19 13:55:21 ottawa kernel: Your time source seems to be instable or some 
driver is hogging interupts

System configuration is dual core Athlon 64 processor running on an NVIDIA 
nFORCE motherboard. Information will be attached
Comment 1 Anssi Johansson 2005-10-24 20:59:35 EDT
I'd recommend trying the new 2.6.13-1.1532_FC4smp kernel. It appears to have
fixed a similar problem for me, although this is based on very preliminary
results. See bug 132439 comment 5 for the description of my problem.
Comment 2 Alexandre Oliva 2005-10-24 23:23:17 EDT
The work arounds you mentioned are, I believe, for a different but similar
problem that gets the kernel clock to run a twice the correct speed.  On nForce
chipsets, it runs at 3x the correct speed, and the workarounds do not work. 
There's a kernel patch floating around that corrects the problem, but it's not
upstream yet.  See http://bugzilla.kernel.org/show_bug.cgi?id=3341 for more info.
Comment 3 a.purkiss 2005-10-25 11:42:50 EDT
(In reply to comment #1)
> I'd recommend trying the new 2.6.13-1.1532_FC4smp kernel. It appears to have
> fixed a similar problem for me, although this is based on very preliminary
> results. See bug 132439 comment 5 for the description of my problem.

Installing this kernel seems to give better clock stability, although I did just 
get the following in dmesg:

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

Comment 4 a.purkiss 2005-10-25 11:46:07 EDT
(In reply to comment #2)
> The work arounds you mentioned are, I believe, for a different but similar
> problem that gets the kernel clock to run a twice the correct speed.  On 
nForce
> chipsets, it runs at 3x the correct speed, and the workarounds do not work. 
> There's a kernel patch floating around that corrects the problem, but it's not
> upstream yet.  See http://bugzilla.kernel.org/show_bug.cgi?id=3341 for more 
info.
> 

I don't believe that the clock runs at 3x, when the machine is idle. When I have 
it under heavy disk I/O load, the clock does run extremely fast (Compiling a 
patched kernel shows this). I'm going to try to repeat the compile with the 2.6.
13-1.1532_FC4smp kernel which I've been running this afternoon. I will report 
back the results.


Comment 5 a.purkiss 2005-10-25 12:08:06 EDT
(In reply to comment #4)
> 
> I don't believe that the clock runs at 3x, when the machine is idle. When I 
have 
> it under heavy disk I/O load, the clock does run extremely fast (Compiling a 
> patched kernel shows this). I'm going to try to repeat the compile with the 2.
6.
> 13-1.1532_FC4smp kernel which I've been running this afternoon. I will report 
> back the results.
> 

A kernel compile (make -j3 all) using the newer kernel gives me only a slight 
clock drift (about 3 seconds in 15 mins). I shall leave this kernel running 
overnight and how accurate the time is in the morning.
Comment 6 a.purkiss 2005-10-25 13:26:32 EDT
(In reply to comment #3)
> (In reply to comment #1)
> > I'd recommend trying the new 2.6.13-1.1532_FC4smp kernel. It appears to have
> > fixed a similar problem for me, although this is based on very preliminary
> > results. See bug 132439 comment 5 for the description of my problem.
> 
> Installing this kernel seems to give better clock stability, although I did 
just 
> get the following in dmesg:
> 
> Losing some ticks... checking if CPU frequency changed.
> 
> 

And this was followed by the following message in dmesg

warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts
rip acpi_processor_idle+0x12f/0x37f
Comment 7 Anssi Johansson 2005-10-25 14:53:19 EDT
Just a quick "me too": The 1532 kernel didn't eliminate the problem completely,
but it did help significantly. I run ntpd -q every 5 minutes to set the clock to
the correct time. With 1526 the average correction amount was a few seconds,
with 1532 the average correction amount dropped to about 0.4 seconds. However,
that's still a bit too much for ntpd to handle without stepping the clock every
once in a while.

I'm still able to make the clock go faster by downloading lots of data or
running 'dd if=/dev/sda of=/dev/null', but the maximum clock error for each 5
minute period has dropped from ~20 seconds to ~6 seconds.
Comment 8 a.purkiss 2005-10-26 11:20:24 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > 
> > I don't believe that the clock runs at 3x, when the machine is idle. When I 
> have 
> > it under heavy disk I/O load, the clock does run extremely fast (Compiling a 
> > patched kernel shows this). I'm going to try to repeat the compile with the 
2.
> 6.
> > 13-1.1532_FC4smp kernel which I've been running this afternoon. I will 
report 
> > back the results.
> > 
> 
> A kernel compile (make -j3 all) using the newer kernel gives me only a slight 
> clock drift (about 3 seconds in 15 mins). I shall leave this kernel running 
> overnight and how accurate the time is in the morning.
> 

The error in the clock time seems to grow with each hour. After rebooting, the 
time seems to gain a few seconds per hour, but after leaving the system running 
for 18 hours, the error have grown to over 10 mins in the hour. 

I have been updating the time using a cron job which runs /usr/sbin/ntpdate 
hourly to resync with our ntp server, saving the output to the following file. 
You can see that the time is stable for a few hours, but the offset get 
progressively bigger and multiple resyncs per hour are needed.

In the morning, the keyboard was also misbehaving, with multiple characters 
appearing for a single keypress. The machine was rebooted after 1pm.

Contents of /root/ntpupdate.log

25 Oct 12:01:01 ntpdate[26659]: adjust time server 193.61.34.17 offset -0.000731 
sec
25 Oct 13:01:01 ntpdate[27259]: adjust time server 193.61.34.17 offset -0.003278 
sec
25 Oct 14:01:01 ntpdate[4290]: adjust time server 193.61.34.17 offset -0.076968 
sec
25 Oct 15:01:02 ntpdate[4851]: adjust time server 193.61.34.17 offset 0.061059 
sec
25 Oct 16:01:00 ntpdate[5350]: step time server 193.61.34.17 offset -0.797082 
sec
25 Oct 17:00:59 ntpdate[7512]: step time server 193.61.34.17 offset -3.905549 
sec
25 Oct 18:00:56 ntpdate[22893]: step time server 193.61.34.17 offset -5.101751 
sec
25 Oct 18:01:01 ntpdate[22898]: adjust time server 193.61.34.17 offset -0.014352 
sec
25 Oct 19:00:54 ntpdate[6238]: step time server 193.61.34.17 offset -8.276370 
sec
25 Oct 19:01:01 ntpdate[6245]: adjust time server 193.61.34.17 offset 0.000447 
sec
25 Oct 20:00:39 ntpdate[6890]: step time server 193.61.34.17 offset -22.329354 
sec
25 Oct 20:01:01 ntpdate[6897]: adjust time server 193.61.34.17 offset -0.288715 
sec
25 Oct 21:00:17 ntpdate[7383]: step time server 193.61.34.17 offset -44.080752 
sec
25 Oct 21:01:00 ntpdate[7394]: step time server 193.61.34.17 offset -1.401230 
sec
25 Oct 21:59:38 ntpdate[7882]: step time server 193.61.34.17 offset -82.791160 
sec
25 Oct 22:01:01 ntpdate[7897]: step time server 193.61.34.17 offset -1.039618 
sec
25 Oct 22:59:13 ntpdate[8384]: step time server 193.61.34.17 offset -108.489768 
sec
25 Oct 23:00:57 ntpdate[8405]: step time server 193.61.34.17 offset -3.536683 
sec
25 Oct 23:58:20 ntpdate[8892]: step time server 193.61.34.17 offset -161.929904 
sec
26 Oct 00:00:55 ntpdate[8917]: step time server 193.61.34.17 offset -5.444595 
sec
26 Oct 00:01:01 ntpdate[8924]: adjust time server 193.61.34.17 offset -0.000301 
sec
26 Oct 00:57:49 ntpdate[9410]: step time server 193.61.34.17 offset -191.851274 
sec
26 Oct 01:00:53 ntpdate[9441]: step time server 193.61.34.17 offset -7.676677 
sec
26 Oct 01:01:01 ntpdate[9447]: adjust time server 193.61.34.17 offset -0.404487 
sec
26 Oct 01:57:32 ntpdate[9933]: step time server 193.61.34.17 offset -209.601732 
sec
26 Oct 02:00:51 ntpdate[9967]: step time server 193.61.34.17 offset -10.295173 
sec
26 Oct 02:01:01 ntpdate[9973]: adjust time server 193.61.34.17 offset -0.001330 
sec
26 Oct 02:56:14 ntpdate[10458]: step time server 193.61.34.17 offset -288.736786 
sec
26 Oct 03:00:34 ntpdate[10501]: step time server 193.61.34.17 offset -27.247606 
sec
26 Oct 03:00:59 ntpdate[10510]: step time server 193.61.34.17 offset -2.095734 
sec
26 Oct 03:55:13 ntpdate[10998]: step time server 193.61.34.17 offset -347.737031 
sec
26 Oct 04:00:33 ntpdate[11049]: step time server 193.61.34.17 offset -27.572619 
sec
26 Oct 04:01:01 ntpdate[11057]: adjust time server 193.61.34.17 offset 0.000225 
sec
26 Oct 04:55:10 ntpdate[12384]: step time server 193.61.34.17 offset -350.720852 
sec
26 Oct 05:00:34 ntpdate[12435]: step time server 193.61.34.17 offset -27.692496 
sec
26 Oct 05:00:59 ntpdate[12445]: step time server 193.61.34.17 offset -1.930641 
sec
26 Oct 05:55:01 ntpdate[12931]: step time server 193.61.34.17 offset -359.545238 
sec
26 Oct 06:00:28 ntpdate[12983]: step time server 193.61.34.17 offset -32.382734 
sec
26 Oct 06:01:01 ntpdate[12993]: step time server 193.61.34.17 offset -0.703683 
sec
26 Oct 06:54:03 ntpdate[13477]: step time server 193.61.34.17 offset -417.875585 
sec
26 Oct 07:00:11 ntpdate[13539]: step time server 193.61.34.17 offset -50.917891 
sec
26 Oct 07:00:56 ntpdate[13550]: step time server 193.61.34.17 offset -5.321547 
sec
26 Oct 07:00:58 ntpdate[13556]: step time server 193.61.34.17 offset -3.039233 
sec
26 Oct 07:54:29 ntpdate[14042]: step time server 193.61.34.17 offset -392.091260 
sec
26 Oct 08:00:25 ntpdate[14099]: step time server 193.61.34.17 offset -36.078240 
sec
26 Oct 08:01:01 ntpdate[14109]: step time server 193.61.34.17 offset -1.639706 
sec
26 Oct 08:53:05 ntpdate[14594]: step time server 193.61.34.17 offset -476.112815 
sec
26 Oct 09:00:14 ntpdate[14662]: step time server 193.61.34.17 offset -47.299761 
sec
26 Oct 09:00:55 ntpdate[14673]: step time server 193.61.34.17 offset -6.135983 
sec
26 Oct 09:01:01 ntpdate[14678]: adjust time server 193.61.34.17 offset 0.000357 
sec
26 Oct 09:53:21 ntpdate[15164]: step time server 193.61.34.17 offset -460.876145 
sec
26 Oct 10:00:04 ntpdate[15230]: step time server 193.61.34.17 offset -57.536578 
sec
26 Oct 10:00:54 ntpdate[15243]: step time server 193.61.34.17 offset -6.494857 
sec
26 Oct 10:01:01 ntpdate[15249]: adjust time server 193.61.34.17 offset -0.000936 
sec
26 Oct 10:52:01 ntpdate[15733]: step time server 193.61.34.17 offset -539.987567 
sec
26 Oct 10:59:49 ntpdate[15809]: step time server 193.61.34.17 offset -72.814939 
sec
26 Oct 11:00:50 ntpdate[15824]: step time server 193.61.34.17 offset -10.825788 
sec
26 Oct 11:00:59 ntpdate[15830]: step time server 193.61.34.17 offset -2.951673 
sec
26 Oct 11:51:27 ntpdate[16314]: step time server 193.61.34.17 offset -576.527315 
sec
26 Oct 11:59:35 ntpdate[16396]: step time server 193.61.34.17 offset -86.255815 
sec
26 Oct 12:00:54 ntpdate[16412]: step time server 193.61.34.17 offset -7.281041 
sec
26 Oct 12:01:01 ntpdate[16418]: step time server 193.61.34.17 offset -1.038729 
sec
26 Oct 12:50:47 ntpdate[16935]: step time server 193.61.34.17 offset -614.813707 
sec
26 Oct 12:58:49 ntpdate[17074]: step time server 193.61.34.17 offset -133.818176 
sec
26 Oct 13:00:28 ntpdate[17096]: step time server 193.61.34.17 offset -33.732859 
sec
26 Oct 13:00:52 ntpdate[17106]: step time server 193.61.34.17 offset -11.968261 
sec
26 Oct 13:00:58 ntpdate[17112]: step time server 193.61.34.17 offset -3.263863 
sec
Comment 9 Anssi Johansson 2005-11-09 20:06:53 EST
Created attachment 120867 [details]
A graph showing the correction amount for each 5 minute period

The clock is still drifting significantly with 2.6.13-1.1532_FC4smp. I made a
quick graph about the drift rate to illustrate the problem. The graph shows how
many seconds ntpd sets the clock back every 5 minutes, and as can be seen from
the graph the current rate is about 5-10 seconds for every 5 minutes. The data
for the graph is from November 1st to November 9th, and can be compared with
the statistics that can be found from http://jaguaari.miuku.net/

Any ideas for what might be causing this?
Comment 10 Dave Jones 2005-11-10 16:55:09 EST
Mass update to all FC4 bugs:

An update has been released (2.6.14-1.1637_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 11 Anssi Johansson 2005-11-11 06:20:08 EST
I installed 2.6.14-1.1637_FC4smp last night and at this moment things look okay
and the error should be manageable by simply running ntpd. However, as mentioned
in comment #8, the error used to grow after the system had been up for a while.
This can also be seen from my graph attached to comment #9. At the time that
graph was drawn the system had been up for 17 days.

So, I'm not drawing any conclusions yet. The impatient among you can have a look
at live stats at http://jaguaari.miuku.net/stats/drift.html which shows the
amount of error correction applied (in milliseconds) every 5 minutes. I'll give
it a couple of days..

When I was still running the older kernel (2.6.13-1.1532_FC4smp) I was even able
to make the clock go backwards:

Fri Nov 11 02:13:12 EET 2005
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:13 EET 2005
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:12 EET 2005  <--
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:13 EET 2005
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:13 EET 2005
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:14 EET 2005
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:13 EET 2005  <--
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:14 EET 2005
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:14 EET 2005
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:15 EET 2005
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:14 EET 2005  <--
[anssi@jaguaari ~]$ date
Fri Nov 11 02:13:15 EET 2005

Huh? Let's hope the new kernel behaves better.
Comment 12 a.purkiss 2005-11-11 09:17:29 EST
(In reply to comment #10)
> Mass update to all FC4 bugs:
> 
> An update has been released (2.6.14-1.1637_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.
> 
> 

The kernel 2.6.14-1.1637_FC4smp panics on my system. I think (although I'm not 
completely sure) that there is a problem with the sata_nv driver. The Kernel 
starts and then stops when trying to mount the root file system. I've attempted 
to load the relevant modules into the initrd, but still get a kernel panic.

I'll have to stick with the 2.6.13-1.1532 kernel for now, which is still 
behaving as before.
Comment 13 Anssi Johansson 2005-11-20 11:43:19 EST
(In reply to comment #11)
> So, I'm not drawing any conclusions yet. The impatient among you can have a look
> at live stats at http://jaguaari.miuku.net/stats/drift.html which shows the
> amount of error correction applied (in milliseconds) every 5 minutes. I'll give
> it a couple of days..

Well, I've now given it a full week to show any possible problems. The graphs
look quite boring at the moment, there's only a 7ms correction applied every 5
minutes, or about 2 seconds per day. This sounds like a normal value, and I'll
now probably switch to running ntpd in the normal daemon mode to correct the
remaining drift. Thanks, I consider this case closed at least for me. I'll have
the original reporter to have the final word, though.
Comment 14 a.purkiss 2005-11-21 11:13:53 EST
(In reply to comment #12)
> (In reply to comment #10)
> > Mass update to all FC4 bugs:
> > 
> > An update has been released (2.6.14-1.1637_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.
> > 
> > 
> 
> The kernel 2.6.14-1.1637_FC4smp panics on my system. I think (although I'm not 
> completely sure) that there is a problem with the sata_nv driver. The Kernel 
> starts and then stops when trying to mount the root file system. I've 
attempted 
> to load the relevant modules into the initrd, but still get a kernel panic.
> 
> I'll have to stick with the 2.6.13-1.1532 kernel for now, which is still 
> behaving as before.

This issue is still not resolved for me, as the new kernel does not install. I 
have not had the time to try to find the problem with the new kernel, but will 
have time tomorrow to try a compilation from source.
Comment 15 Dave Jones 2006-02-03 02:28:40 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 16 Alexandre Oliva 2006-03-04 07:31:28 EST
Just got this again after a power-cycle on my wife's notebook.  It was running
yesterday's Fedora Core devel kernel: 2.6.15-1.2008_FC5.  Oh well...
Comment 17 Patrick 2006-06-06 04:49:55 EDT
I have this exact problem using 2.6.16 (upgraded from 2.6.11) on 20 identical
Opteron 165 (dual core) Nforce4 (Tyan 2865) machines.  8/20 had clock problems
and 4 of those could be fixed by adding the kernel option clock=pmtmr or
clock=tsc.  The rest seem hopeless.  I read that this problem could be fixed by
turning off spread spectrum FSB in the BIOS:

http://fcp.homelinux.org/modules/newbb/viewtopic.php?topic_id=21792&forum=10&post_id=90434

I will try this.  Please post any recent news on this if there is any.  Thanks.
Comment 18 Dave Jones 2006-09-16 23:21:02 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 19 Dave Jones 2006-10-16 20:40:30 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 20 Dave Jones 2006-11-24 18:06:47 EST
This bug has been mass-closed along with all other bugs that
have been in NEEDINFO state for several months.

Due to the large volume of inactive bugs in bugzilla, this
is the only method we have of cleaning out stale bug reports
where the reporter has disappeared.

If you can reproduce this bug after installing all the
current updates, please reopen this bug.

If you are not the reporter, you can add a comment requesting
it be reopened, and someone will get to it asap.

Thank you.

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