Bug 114869 - date returns future year of 586562
Summary: date returns future year of 586562
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jim Paradis
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-02-03 19:29 UTC by steve moss
Modified: 2013-08-06 01:03 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-12 01:08:26 UTC
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 04:00:00 UTC

Description steve moss 2004-02-03 19:29:01 UTC
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 22:27:15 UTC
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 18:51:44 UTC
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 23:36:32 UTC
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 18:59:02 UTC
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 17:22:27 UTC
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-12 01:08:26 UTC
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.