Bug 74645 - OS clock is too slow, clock skew of 8-10s/hour (on Dell laptops?)
OS clock is too slow, clock skew of 8-10s/hour (on Dell laptops?)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-28 17:48 EDT by Aleksey Nogin
Modified: 2008-08-01 12:22 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simple program to increase a tick value. (747 bytes, text/plain)
2002-10-02 17:33 EDT, Aleksey Nogin
no flags Details

  None (edit)
Description Aleksey Nogin 2002-09-28 17:48:21 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.

/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.
Comment 1 Aleksey Nogin 2002-09-29 20:44:02 EDT
Using the adjtimex, I get tick=1953. If I change that to 1957, the clock skew
goes away.
Comment 2 Aleksey Nogin 2002-10-02 17:32:41 EDT
See also bug 64772.
Comment 3 Aleksey Nogin 2002-10-02 17:33:33 EDT
Created attachment 78265 [details]
Simple program to increase a tick value.
Comment 4 Aleksey Nogin 2002-10-02 17:36:25 EDT
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.
Comment 5 James Segarra 2002-10-13 18:21:33 EDT
This happens to me as well. I have a Dell Inspiron 8100 512Mb 1000MHz running
RHL8.0.
Comment 6 Kevin Seghetti 2002-10-21 17:04:57 EDT
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.
Comment 7 Need Real Name 2002-10-22 15:38:43 EDT
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
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

Comment 8 Brian G. Anderson 2002-10-29 17:22:06 EST
I have a Dell Latitude 840 running at 2Ghz with the same problem.
Comment 9 Brian G. Anderson 2002-10-29 17:56:03 EST
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.
Comment 10 Aleksey Nogin 2002-11-22 01:30:22 EST
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!
Comment 11 Need Real Name 2002-11-22 13:06:15 EST
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
Comment 12 Bill Mill 2002-11-25 09:19:15 EST
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.
Comment 13 Arjan van de Ven 2002-11-25 09:22:23 EST
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 ?
Comment 14 Aleksey Nogin 2002-11-25 10:55:15 EST
> 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...
Comment 15 Bill Mill 2002-12-01 20:12:17 EST
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.
Comment 16 Asa Dotzler 2002-12-04 01:04:13 EST
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.
Comment 17 Bill Mill 2002-12-08 16:23:04 EST
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.
Comment 18 Craig Lawson 2003-02-02 20:21:35 EST
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.
Comment 19 lewing 2003-02-15 22:11:21 EST
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.
Comment 20 Joao Henriques de Jesus 2003-02-28 14:52:10 EST
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.
Comment 21 Brett L. Becker 2003-03-03 19:43:38 EST
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... 
Comment 22 Jason Merrill 2003-07-22 22:40:00 EDT
I still have this problem with a Dell Latitude C600 running Phoebe.
Comment 23 Bugzilla owner 2004-09-30 11:39:57 EDT
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/

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