> Hello,
>
> I have an old Sun Ultra 10 with a dead motherboard battery. After
> cold-starting the machine the hardware clock now always indicates the
> date as being January 1 1968. Strange things then happen when I boot
> OpenBSD (10.10.6.10 and 10.10.6.11 are my local time servers):
[...]
> The warning to check the date is clear enough, though I was still a
> bit surprised to see both named and ntpd fail. I don't know why named
> cares so much about the date but I'll assume there's a good reason. I
> also don't know why or how OpenBSD transforms 01/01/1968 into November
> 26 1931, but then again, once the battery is dead I guess the hardware
> can be considered broken and all bets are off.
>
> Note that the initial warning indicates that the clock lost 21038
> days, which is about 57.6 years. 2010.4 (~ today) + 57.6 = 2068 =
> 1968 + 100, so it looks like the computation is done modulo 100. I
> would have expected to see a value like (2010.4 - 1931.8)*365 = 28689
> days lost.
A bug causes the initial time to be interpreted as 2068 instead of 1968.
And then 2068 causes a 32 bit time_t wraparound, which causes the kernel
to believe that you are in late 1931 instead.
The following diff should fix this issue, can you give it a try? (apply
in sys/dev/ic/)
Index: mk48txx.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/mk48txx.c,v
retrieving revision 1.5
diff -u -p -r1.5 mk48txx.c
--- mk48txx.c 26 Jun 2008 05:42:15 -0000 1.5
+++ mk48txx.c 7 Jun 2010 20:56:06 -0000
@@ -156,7 +156,8 @@ mk48txx_gettime(handle, tv)
year = FROMBCD(bus_space_read_1(bt, bh, clkoff + MK48TXX_IYEAR));
year += mk->mk_year0;
- if (year < POSIX_BASE_YEAR && mk48txx_auto_century_adjust != 0)
+ if (year < POSIX_BASE_YEAR && mk48txx_auto_century_adjust != 0 &&
+ mk->mk_year0 >= POSIX_BASE_YEAR)
year += 100;
dt.dt_year = year;
