Red Hat Bugzilla – Bug 74645
OS clock is too slow, clock skew of 8-10s/hour (on Dell laptops?)
Last modified: 2008-08-01 12:22:52 EDT
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.
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
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).
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
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@1.6Ghz
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
/sbin/hwclock ; date
Mon 21 Oct 2002 05:40:34 PM CST -0.237234 seconds
Mon Oct 21 17:40:33 CST 2002
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,
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
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
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
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/