Bug 8123 - clock/hwclock utilities die since 0101-2000
Summary: clock/hwclock utilities die since 0101-2000
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: clock
Version: 5.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
: 8108 8134 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-01-03 03:07 UTC by typo
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-02-05 18:40:02 UTC
Embargoed:


Attachments (Terms of Use)

Description typo 2000-01-03 03:07:32 UTC
outpost:~# clock
mktime() failed unexpectedly (rc -1).  Aborting.
outpost:~# rpm -qf /sbin/clock
util-linux-2.7-15
outpost:~# cat /etc/redhat-release
release 5.0 (Hurricane)
outpost:~# uname -a
Linux outpost.boehm.org 2.0.35 #1 Thu Oct 29 16:02:50 CET 1998 i586 unknown
outpost:~# uptime
  4:12am  up 184 days, 14:46,  1 user,  load average: 0.01, 0.02, 0.00
outpost:~# cat /proc/cpuinfo
processor       : 0
cpu             : 586
model           : Pentium 75+
vendor_id       : GenuineIntel
stepping        : 5
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : yes
fpu             : yes
fpu_exception   : yes
cpuid           : yes
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8
bogomips        : 36.04

is this a hardware problem or is it the clock util?
i normally periodically use `clock -uw` or `hwclock -uw`
to sync my hwclock... problem first appeared on 0101-2000 01:01
(well.. that's the first time it was in use since the new year).

Comment 1 Bill Nottingham 2000-01-03 16:06:59 UTC
*** Bug 8134 has been marked as a duplicate of this bug. ***

Comment 2 Bill Nottingham 2000-01-03 16:08:59 UTC
*** Bug 8108 has been marked as a duplicate of this bug. ***

Comment 3 Gilbert E. Detillieux 2000-01-07 21:49:59 UTC
I'm seeing the same problem with util-linux-2.8-11, under Red Hat 5.2.
With that version, at least, the error message only shows up when /dev/rtc
is not available (e.g. if it's busy due to some other software like VMware),
in which case hwclock is going directly to the hardware clock.

The following patch seems to have fixed the problem for me.

--- util-linux-2.8/sys-utils.orig/hwclock.c	Thu Jun 11 17:30:55 1998
+++ util-linux-2.8/sys-utils/hwclock.c	Fri Jan  7 15:07:01 2000
@@ -845,6 +845,9 @@
            */
         if (hclock_read_bcd(9) >= 70) tm->tm_year = hclock_read_bcd(9);
         else tm->tm_year = hclock_read_bcd(9) + 100;
+	if (debug)
+	   printf ("Year read from old Hardware Clock: c=%02d, y=%02d,
tm_year=%02d\n",
+		   hclock_read_bcd(50), hclock_read_bcd(9), tm->tm_year);
       } else {
         tm->tm_year = hclock_read_bcd(50) * 100 + hclock_read_bcd(9) - 1900;
         /* Note: Byte 50 contains centuries since A.D.  Byte 9 contains
@@ -854,6 +857,10 @@
            conceivably be years since the beginning of the current
            century.  If so, this code won't work after 1999.
            */
+	if (tm->tm_year < 70) tm->tm_year += 100;	/* Y2K bug */
+	if (debug)
+	   printf ("Year read from new Hardware Clock: c=%02d, y=%02d,
tm_year=%02d\n",
+		   hclock_read_bcd(50), hclock_read_bcd(9), tm->tm_year);
       }
       /* Unless the clock changed while we were reading, consider this
          a good clock read .

This fix is essentially just the one line.  The debug printf code is not
necessary, of course, but it helped me to find out what was going on.  After
running the patched hwclock program, with the -w option, the century byte was
correctly updated, and now shows up as 20, as it should.  (I imagine that
rebooting the system would have allowed the BIOS to update the century byte on
its own, which would have eliminated the need for this patch, but it wasn't
convenient for me to reboot the system in question.)

Comment 4 Bill Nottingham 2000-02-05 18:40:59 UTC
This is fixed in the current util-linux.


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