Bug 85053 - Kernel has a problem keeping time
Kernel has a problem keeping time
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-25 00:29 EST by Darcy Birkbeck
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:34 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)

  None (edit)
Description Darcy Birkbeck 2003-02-25 00:29:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206

Description of problem:
Bad:  The Kernel clock loses synchronization and has actually reversed direction

We have been trying to find this problem for some time.  Our servers will lose
time synchronization, applications will not run correctly and in some instances
we are not able to login to the machine.  A reboot is necessary to fix the
problem.  (In our latest case, time can actually be seen going in reverse! - See
below)

Background:
We have two types of servers:  NEC MC2400s and HP LP2000Rs.  Both of which are
dual PIII processor, have 1GB of RAM and a Mylex RAID controller.  Our NEC
MC2400s do not exibit this problem.  The HP LP2000Rs do.

All servers are currently running kernel version 2.4.18-19.7.xsmp.  (This bug
did not appear in the older 2.4.9 kernels)

If ntpd is turned off, the server will eventually drift days or months off of
the correct time.

Since we run ntp by default, it is difficult to ascertain when exactly this
problem begins.  We do know that it gets bad enough that ntpd is no longer able
to keep system synchronization.

Most of our HP LP2000R servers have shown this behaviour at least once.

Version-Release number of selected component (if applicable):


How reproducible:
Didn't try


Additional info:

The following was gleamed from a server experiencing the problem.

Mon Feb 24 21:36:30 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:31 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:30 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:33 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:30 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:31 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:32 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:33 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:30 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:31 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:32 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:32 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:33 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:30 MST 2003
[root@sr3dt rc.d]# date
Mon Feb 24 21:36:31 MST 2003

It appears as though the last 2 bits of the clock just loop!
Comment 1 Gurdeep Singh 2003-09-05 06:49:09 EDT
we are also facing the similar issue with date on HP LP1000R running RedHat 7.2 
with kernel versions 2.4.18-17 and 2.4.18-27 SMP.
[gurdeep@test_mac1 /]$ date;/sbin/hwclock --show;date 
Mon Sep  1 05:15:10 PDT 2003 
Wed Sep  3 01:49:01 2003  0.314047 seconds 
Mon Sep  1 05:15:11 PDT 2003 
[gurdeep@test_mac1 /]$ ps -ef|grep -i ntp
ntp      13222     1  0 04:30 ?        00:00:00 [ntpd]
gurdeep  32629 32530  0 05:15 pts/0    00:00:00 grep -i ntp
[gurdeep@test_mac1 /]$ date;/sbin/hwclock --show;date 
Mon Sep  1 05:15:10 PDT 2003 
Wed Sep  3 01:49:16 2003  0.048416 seconds 
Mon Sep  1 05:15:11 PDT 2003 
[gurdeep@test_mac1 /]$ date;/sbin/hwclock --show;date 
Mon Sep  1 05:15:11 PDT 2003 
Wed Sep  3 01:49:21 2003  -0.297336 seconds 
Mon Sep  1 05:15:11 PDT 2003 
[gurdeep@test_mac1 /]$ date;/sbin/hwclock --show;date 
Mon Sep  1 05:15:11 PDT 2003 
Wed Sep  3 01:49:24 2003  0.070420 seconds 
Mon Sep  1 05:15:11 PDT 2003 
[gurdeep@test_mac1 /]$ uname -a 
Linux test_mac1.Cadence.COM 2.4.18-27.7.xsmp #1 SMP Fri Mar 14 05:52:30 EST 
2003 i686 unknown 
[gurdeep@test_mac1 /]$ cat /etc/issue 
Red Hat Linux release 7.2 (Enigma) Kernel \r on an \m

[gurdeep@test_mac1 /]$
######################################################################3
root@test_mac2 conf]$ date;/sbin/hwclock --show;date 
Wed Sep  3 02:28:25 PDT 2003 
Wed Sep  3 03:06:41 2003  -0.009537 seconds 
Wed Sep  3 02:28:25 PDT 2003
[root@test_mac2 conf]$ date ; /sbin/hwclock --show ; date 
Wed Sep  3 02:28:25 PDT 2003 
Wed Sep  3 03:06:43 2003  0.068449 seconds 
Wed Sep  3 02:28:25 PDT 2003
[root@test_mac2 conf]$ date ; /sbin/hwclock --show ; date 
Wed Sep  3 02:28:25 PDT 2003 
Wed Sep  3 03:06:45 2003  -0.196040 seconds 
Wed Sep  3 02:28:25 PDT 2003
[root@test_mac2 conf]$ date ; /sbin/hwclock --show ; date 
Wed Sep  3 02:28:25 PDT 2003 
Wed Sep  3 03:06:47 2003  0.020043 seconds 
Wed Sep  3 02:28:25 PDT 2003
[root@test_mac2 conf]$
[root@test_mac2 conf]$ date ; /sbin/hwclock --show ; date 
Wed Sep  3 02:28:25 PDT 2003 
Wed Sep  3 03:06:49 2003  -0.193202 seconds 
Wed Sep  3 02:28:25 PDT 2003
[root@test_mac2 conf]$
[root@test_mac2 conf]$ date ; /sbin/hwclock --show ; date 
Wed Sep  3 02:28:25 PDT 2003 
Wed Sep  3 03:06:52 2003  0.000749 seconds 
Wed Sep  3 02:28:25 PDT 2003
[root@test_mac2 conf]$
[root@test_mac2 conf]$ uname -a
Linux test_mac2.Cadence.COM 2.4.18-17.7.xsmp #1 SMP Tue Oct 8 12:37:04 EDT 2002 
i686 unknown
Comment 2 Bugzilla owner 2004-09-30 11:40:34 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.