Subject: Re: Clock problem
To: Magni Onsoien <magnio@pvv.ntnu.no>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 01/06/1999 17:45:57
In message <Pine.BSF.4.05.9901070015200.17708-100000@verden.pvv.ntnu.no>Magni Onsoien writes
>My DECStation 5000/25 is running NetBSD 1.3.2.
>
>This morning it suddenly crashed. When it was on its way up, there was
>some '?RTC' above the boot prompt, but no errors when typing boot. It came
>up, but during boot it suddenly told me that its clock had lost 736 days
>(WARNING: Clock has lost 736 days) - the usual message used to be that it
>has gained some days. After the usual boot-things like fsck, network setup
>etc it is supposed to run a ntpdate against the usual ntp-server, and so
>it does. It then displays that it has adjusted the time by 63574248.856601
>sec. Then it just stands there for ~15 minutes, with the ntp-message as
>the last message. Then the boot continues in the normal way.
>
>When booting in single user 'date' says Jan 1 1997...
>
>A friend of mine (the Cc of this mail is for her) with exactly the same
>computer is experiencing the same problem.
>
>Anyone got any ideas?

The DECstation PROM uses the RTC as a time-of-year clock and forces
the RTC to always be in either 1972 or 1973.  (If the RTC is outside
that range, the PROM resets it'; hence the ??? mesage).

The 1.3.x kernels (indeed everything since 4.4bsd/pmax) use a fixed
year-offset to map that time-of-year to a correct year.  Then they
check that against the time-of-year extracted from the root
filesystem.  that's where the warning came from.

The simple fix is to move to a 1.3.3 kernel, where the constant offset
is fixed by one. (can you say y2k bug?)  Otherwise, you can bump
DEC_YR_OFFSET or whatever the constant is called.

-Current has a proper fix for this. Thanks to Matthias(?) the fixed
offset is not present anymore. I suppose we could pull the -current
code up for any future 1.3.4 release.