If I disable time synchronization (ntp, etc), the OS clock is consistenly running 8-10s/hour behind while the HW clock seems to be much more accurate. This is a DELL Lattitude C640 laptop. /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz stepping : 4 cpu MHz : 1196.470 cache size : 512 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 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 2366.82 Another person in our goup has Dell Inspiron and is running kernel.org 2.4.18 on RedHat 7.x (x=2 or 3) and has exactly the same problem.
Using the adjtimex, I get tick=1953. If I change that to 1957, the clock skew goes away.
See also bug 64772.
Created attachment 78265 [details] Simple program to increase a tick value.
Workaround for this problem is to compile an attached program and have it ran at boot time *once* (running it once will make your clock too fast). I use ti::once:/usr/local/sbin/tick_incr line in /etc/inittab bewteen the "si" sysinit and "l0"-"l6" rc lines.
This happens to me as well. I have a Dell Inspiron 8100 512Mb 1000MHz running RHL8.0.
FYI: I also experienced this, and had my pointer freeze for short time every two seconds. After some experimentation I discovered the problem was the battery monitor application, every time it reads the battery level everything freezes for a short time. If interrupts are disabled while this happens then the Linux clock will slowly fall behind. I was able to make it tolerable by setting the battery monitor to only update once a minute, and then added a cron job to re-read the hwclock every hour.
Hi, I have the same problem in a IBM 6792 Netvista Model 6792-11S, P4 768MB RAM using RAID 1 in the kernel, running redhat 8.0 with latest errata applied, the machine has APM disabled in BIOS,I don't installed the apmd rpm (this is a desktop machine) and is loosing ten minutes at day, by example: yesterday I sync the rtc clock and system clock with hwclock and running: /sbin/hwclock ; date Mon 21 Oct 2002 05:40:34 PM CST -0.237234 seconds Mon Oct 21 17:40:33 CST 2002 and today /sbin/hwclock; date Tue 22 Oct 2002 02:22:29 PM CDT 0.365991 seconds Tue Oct 22 14:12:26 CDT 2002 and seems which lost ten minutes in a day, I have another computer identical but with only 384MB RAM ando no md raid and don't show the problem, the difference is which this machine is sitting idle, thanks in advance, Gabriel
I have a Dell Latitude 840 running at 2Ghz with the same problem.
One other note on the Latitude 840. I disabled the battery applet based on some of the comments attached to this bug. In order to check my battery level, I go into the Dell's setup screens <fn><setup> (yess dell allows you to enter these screens while the computer is running). Upon exiting and returning to X, the time reported by RH8.0 is now incorrect. This is completely repeatable and the hardware clock is fine.
Yeah, this seems to be APM related - when I disabled APM (and enables ACPI) is the kernel, the problem went away. I also tried enabling CONFIG_APM_ALLOW_INTS, but that didn't help any... Weird!
seems which the bug is dependant in the workload of the machine, at least in my case, because when a ripped 10 cd to ogg format (that lasted a 4-5 hours, where the use of cpu was at least 80 %, from top readings) the machine lost aprox 9 minutes in the system clock, the hardware clock was fine
Confirm problem for both my laptop and my friend's identical model (dell latitude c610) laptop. I think the priority should be high on this, as having a correct clock on the computer is a pretty important feature, I know it annoys the heck out of me. Also, I lose more than 8-10 secs, I lose about 3 minutes an hour.
does that still happen without battery monitor app? (or with it set to not query as often) does it still happen if you install ntp ?
> does that still happen without battery monitor app? At some point I've compiled my kernel with ACPI - couldn't suspend my laptop and couldn;t get battery status, but the time ran OK. > does it still happen if you install ntp ? Sort of - NTP can not sync when the drift is bigger than 500PPM (e.g. 1.8s/hour), so it just steps the time every 15m. Of course, this also means that when the machine is off the network, ntp can not do much and the time is still wrong. P.S. Dell Latitude C640 System BIOS, A04 (relased Nov 12, 2002) has the following in the release notes: > 2. Improved battery status reporting algorithm to reduce time spent > in SMM when updating the OS battery information. I am still running A03 (upgrading the BIOS requires finding a DOS boot disk somewhere, and I do not have such stuff around), but I am wondering if A04 would make any difference on this issue...
Enabling NTP with the battery monitor applet visible makes no difference, I lose just as much time as when it is disabled. Currently, with no battery monitor applet and NTP enabled, I seem to have the correct time.
I had this problem with RH8 on a Dell Latitude C840. The clock skew was so bad that ntp couldn't even keep up. After I disabled the display power management (prefs -> screen saver -> advanced tab) the problem went away or was diminished enough that ntp has been able to keep the clock synced.
I have set the power management to off, and even without the battery monitor applet, my clock is slow. Without the battery monitor applet, the problem is not as bad, but NTP does eventually fall out of sync.
I discovered a similar problem on my desktop system today. My system has a 933 MHz P-III and is neither a Dell nor a laptop. I have a CD writer drive as the primary on IDE-1 and a CD-ROM drive as the secondary. If I run cdrdao in non "on-the-fly" mode (finishes reading the entire source CD before writing), my clock slows by around 50%. If I watch my clock applet, I can see the second hand ticking off seconds twice as slow as it should be. After a 20 minute operation, the clock has lost approximately 10 minutes. I am using RH 7.3 with the 2.4.18-17.7.x kernel. I am not using APM. Generally my system loses less than 5 seconds/day, and I have NTP adjust the clock once a day or more. My guess is that this is due to incorrect interrupt priorities. The ATAPI devices are blocking the clock interrupt. It has nothing to do with laptops.
I've seen system clock related problems on an Inspiron 4150 and and Inspriron 8200 that were definitely caused by the gnome battery applet reading from /proc/apm. I was also getting corrupt serial data from both a serial wacom Intuos and a USB camera. Disabling the battery applet avoided triggering the problem on both machines, all the devices are working properly now.
I have a Dell C510 laptop with RH8 and W2K and version 14 of Dell Bios. Linux OS clock gets skew 30-90s/hour, but W2K is OK. The ammount of time the OS clock gets skewed is not constant, which seems to indicate that depends on active jobs. I was not abble to find all the jobs dependency, but the battery applet seems to be one of them.
Running Inspiron 5000 here with latest phoebe + rawhide gnome and several other rawhide packages... I did have this skew problem with 8.0, but when I upgraded to phoebe, it went away and the clock is fine. I have apm enabled and am running the clock applet. Just thought you'd like to know...
I still have this problem with a Dell Latitude C600 running Phoebe.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/