Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 114869 - date returns future year of 586562
date returns future year of 586562
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jim Paradis
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-02-03 14:29 EST by steve moss
Modified: 2013-08-05 21:03 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-11 21:08:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:188 normal SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 2 2004-05-11 00:00:00 EDT

  None (edit)
Description steve moss 2004-02-03 14:29:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; SunOS 5.8 sun4u)

Description of problem:
Incorrect date causes automounter to stop working.  At that time if
you type "date" you will see the date of:

	Wed Aug  4 09:01:29 PST 586562

The month and day will change as our calendar day moves forward, but
the year is always consistent with the reported one above.  If you
look in /var/log/messages, you will see the time stamp of the time
above.  However, if you run hwclock, the date is correct.

The correct date of the machine is:  Tue Feb  3 09:01:58 PST 2004
The reported date of the machine is: Wed Aug  4 09:01:29 PST 586562

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

How reproducible:

Steps to Reproduce:
1. See the automounter no longer mounts NFS mount points
2. Run the "/bin/date" command and you will see the skewed date
3. Run the "/sbin/hwclock" command to verify correct date

Additional info:
Comment 2 Tim Waugh 2004-02-03 17:27:15 EST
If it is causing other problems, the error isn't in 'date' but in the
kernel's time-keeping.
Comment 3 Jim Paradis 2004-02-10 13:51:44 EST
Could you tell me what platform(s) this problem is showing up on, and
attach boot logs from these system(s)?

I suspect that the problem is one that we saw some time ago with TSC
timer handling and that we thought we had fixed.  The reason we may
not have tripped over it until now is that nearly all current AMD64
systems have HPET timers, which have been working correctly (and far
more accurately) as far as we know.  If the RHEL kernel is not
recognizing the HPET timer on your system, I want to know why :)

If it turns out that the TSC bug is still not fixed, then getting the
HPET working will solve your immediate problem.  If it turns out to be
a problem in HPET handling (unlikely) then we'll have to address that
ASAP; in either case console logs will help enormously in finding out
exactly what's going on.
Comment 4 Jim Paradis 2004-02-10 18:36:32 EST
After reviewing some logs sent to me by Mentor:

It's interesting that you're seeing the same thing with both
SLES8 and RHEL3... that suggests a rather fundamental problem.

When I look at roach.log, one thing jumps out at me: with only
a couple of exceptions, every time ntpdate runs it believes 
that the clock is slow by either 4293 seconds (71 min. 33 sec)
or about 140,466,900 seconds (1625 days, 18 hours, 16 min, 40 sec).
The quantum jumps up into the 587th century are occurring
because somehow the pattern of the 4293-second update is showing
up in the *high-order* longword of the 64-bit time_t.  For any
dates that we mortals might see in our lifetimes, the high-order
longword should always be zero.

I'm curious as to why the date seems to be reported as so 
consistently off, even with updates.

I notice that the strange jumps occur right when ntpdate is
run, too.  This suggests to me that there might be an issue
with *updating* the date, rather than timekeeping per se.
Frequent updating of the date along with lots of reading
thereof might trigger a latent race condition.  I'll keep
Comment 5 Jim Paradis 2004-02-13 13:59:02 EST
Update from customer contact: booting with the "notsc" parameter so as
to use only the HPET timer seems to be a good workaround; stability
testing is continuing.

I still want to get to the bottom of this, though.
Comment 6 Ernie Petrides 2004-03-02 12:22:27 EST
A work-around for this problem has just been committed to the
RHEL 3 U2 patch pool (in the internal Engineering build of kernel
version 2.4.21-9.17.EL).  I'll leave this bug in "assigned" state
so that Jim can pursue a final resolution in the future.
Comment 7 John Flanagan 2004-05-11 21:08:26 EDT
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


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