Subject: Re: bin/13578: ntpdate stuck in the 1930's
To: gabriel rosenkoetter <firstname.lastname@example.org>
From: Andrew Cagney <email@example.com>
Date: 07/30/2001 13:36:28
> This isn't a problem we can fix, as I understand it. OpenFirmware is
> just painfully broken.
> Resetting the clock by hand is the only solution (and that won't
> even stick past a reboot unless you do it in MacOS, incidentally
> overwriting your nvramrc and OF vars in the process).
> If you'd like to figure out how MacOS X (well, hopefully, Darwin)
> handles this situation, it'd be great to know.
Hmm, my description was a little vague on specifics.
My problem isn't with the G4 Ti resetting its nvram after a reset.
Rather it is with ntpdate's inability to update the system clock after
such an event has occured. The sequence is:
o machine boots with clock set to 1901
o ntpdate runs, clock adjusted to ~1930
o rerunning ntpdate has no effect - we're
stuck in the 1930s.
I suspect this is an integer overflow/underflow problem rather than an
Try the following, perhaphs on a non PowerPC machine ....
# date 190201010000
Wed Jan 1 00:00:00 EST 1902
# ntpdate ....
12 Jul 10:12:41 ntpdate: step time server .... offset
Wed Jul 12 10:12:49 EDT 1933
# ntpdate ...
12 Jul 10:13:00 ntpdate: adjust time server .... offset -0.004044 sec
Wed Jul 12 10:13:03 EDT 1933
# date 200107301325
Mon Jul 30 13:25:00 EDT 2001
(Just remember to restart a few daemons or the system after doing this -
cron goes for a walk, postfix dumps core, ....)
PS: On a G4 Ti with OF 3.x, setting the date does correctly update the