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
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.
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.
(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.
(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.
(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.
(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
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.
(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
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?
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.
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.
(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.
(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.
(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.
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.
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...
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.
[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.
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.
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.