NetBSD Problem Report #13578
Received: (qmail 29817 invoked from network); 28 Jul 2001 16:18:28 -0000
Message-Id: <20010728162208.77ADB1110F@www.netbsd.org>
Date: Sat, 28 Jul 2001 09:22:08 -0700 (PDT)
From: cagney@mac.com
Sender: nobody@netbsd.org
Reply-To: cagney@mac.com
To: gnats-bugs@gnats.netbsd.org
Subject: ntpdate stuck in the 1930's
X-Send-Pr-Version: www-1.0
>Number: 13578
>Category: bin
>Synopsis: ntpdate stuck in the 1930's
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: bin-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Jul 28 16:20:00 +0000 2001
>Closed-Date: Sat Apr 01 19:46:46 +0000 2023
>Last-Modified: Sat Apr 01 19:46:46 +0000 2023
>Originator: Andrew Cagney
>Release: 1.5.1 Userland, current (2001-07-27) kernel
>Organization:
>Environment:
NetBSD localhost 1.5X NetBSD 1.5X (NETLUX) #7: Fri Jul 27 14:04:00 EDT 2001 boor@localhost:/usr/trunk/sys/arch/macppc/compile/NETLUX macppc
G4 Ti
>Description:
After a hard reset of a G4 Ti, the system clock is set back to 1901.
Running ntpdate gets the machine to advance its clock to ~1930. Running ntpdate again advances the clock no further - it is stuck in the mid 20th century.
To get the machine into the 21st century, the clock needs to be set by hand.
>How-To-Repeat:
Reset a G4 Ti.
Boot the machine (it is 1901)
Run ntpdate to a time server.
>Fix:
>Release-Note:
>Audit-Trail:
From: gabriel rosenkoetter <gr@eclipsed.net>
To: cagney@mac.com
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/13578: ntpdate stuck in the 1930's
Date: Mon, 30 Jul 2001 12:48:53 -0400
On Sat, Jul 28, 2001 at 09:22:08AM -0700, cagney@mac.com wrote:
> After a hard reset of a G4 Ti, the system clock is set back to 1901.
>
> Running ntpdate gets the machine to advance its clock to ~1930. Running ntpdate again advances the clock no further - it is stuck in the mid 20th century.
>
> To get the machine into the 21st century, the clock needs to be set by hand.
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.
--
~ g r @ eclipsed.net
From: Andrew Cagney <cagney@mac.com>
To: gabriel rosenkoetter <gr@eclipsed.net>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/13578: ntpdate stuck in the 1930's
Date: Mon, 30 Jul 2001 13:36:28 -0400
>
> 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
OpenFirmware problem.
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[563]: step time server .... offset
994929055.384305 sec
# date
Wed Jul 12 10:12:49 EDT 1933
# ntpdate ...
12 Jul 10:13:00 ntpdate[567]: adjust time server .... offset -0.004044 sec
# date
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, ....)
Andrew
PS: On a G4 Ti with OF 3.x, setting the date does correctly update the
nvram.
From: gabriel rosenkoetter <gr@eclipsed.net>
To: Andrew Cagney <cagney@mac.com>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/13578: ntpdate stuck in the 1930's
Date: Mon, 30 Jul 2001 14:20:12 -0400
Aha.
You are correct, I was speaking to a separate problem (that NetBSD
doesn't know how to change the hardware clock's idea of the date).
Just tried your steps on an i386 1.5W machine with the same results
(can't get the date past 1933). I would say this is a problem in
ntpd, though.
(It also may *not* be specific to our platform, but rather a problem
in the protocol, btw. I haven't looked at the code, though.)
--
~ g r @ eclipsed.net
State-Changed-From-To: open->feedback
State-Changed-By: martin@netbsd.org
State-Changed-When: Sun, 08 Oct 2006 12:19:37 +0000
State-Changed-Why:
With conversion to the new TODR code there are sanity checks that will
not allow the time to be set to 1901 or 1930 at boot. So while the original
problem might not have been solved, it should be impossible to show up
again in -current.
Is it OK to close this PR?
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 10 Apr 2008 04:08:31 +0000
State-Changed-Why:
Let's get ntpdate fixed too. (Or is it already? I'm putting it on my list of
things to look into, anyway.)
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 22 Feb 2009 08:08:00 +0000
State-Changed-Why:
Does ntpdate behave any better with 64-bit time_t?
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 22 Feb 2009 10:07:15 +0000
State-Changed-Why:
Feedback mail bounced, someone else will have to check (anyone can do this
if they don't mind messing up their clock...)
From: dieter roelants <dieter.NetBSD@pandora.be>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/13578 (ntpdate stuck in the 1930's)
Date: Sun, 22 Feb 2009 12:40:15 +0100
On Sun, 22 Feb 2009 10:07:16 +0000 (UTC)
dholland@NetBSD.org wrote:
> Synopsis: ntpdate stuck in the 1930's
>
> Feedback mail bounced, someone else will have to check (anyone can do this
> if they don't mind messing up their clock...)
Sure. I set my clock to today in 1901. Running ntpdate brought me even
further back, to Thu Jan 16, 1873. So I'd say it isn't fixed. ;)
Starting from somewhere in february 1941, ntpdate does the right thing
(2^31 seconds later than the date 1873, and also 2^31 seconds ago).
(This was on NetBSD/amd64 5.99.7, updated and built yesterday.)
dieter
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/13578 (ntpdate stuck in the 1930's)
Date: Tue, 24 Mar 2009 21:21:59 +0000
On Sun, Feb 22, 2009 at 12:00:07PM +0000, dieter roelants wrote:
>> Feedback mail bounced, someone else will have to check (anyone can do this
>> if they don't mind messing up their clock...)
>
> Sure. I set my clock to today in 1901. Running ntpdate brought me even
> further back, to Thu Jan 16, 1873. So I'd say it isn't fixed. ;)
> Starting from somewhere in february 1941, ntpdate does the right thing
> (2^31 seconds later than the date 1873, and also 2^31 seconds ago).
> (This was on NetBSD/amd64 5.99.7, updated and built yesterday.)
Charming. Well, thanks for testing... clearly someone's going to have
to wade into ntpdate to see waht's going on. I'll put it on my list.
--
David A. Holland
dholland@netbsd.org
From: Jeff Rizzo <riz@tastylime.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/13578
Date: Sat, 31 Dec 2011 15:42:07 -0800
I just tested with 5.1_STABLE:
# date
Wed Jan 1 00:01:01 PST 1902
# ntpdate 2001:470:4867:1::24
31 Dec 15:40:26 ntpdate[525]: step time server 2001:470:4867:1::24
offset -823704534.419839 sec
# date
Sat Dec 31 15:40:28 PST 2011
#
Can someone else verify?
From: Jeff Rizzo <riz@tastylime.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/13578
Date: Sat, 31 Dec 2011 15:58:58 -0800
Ok, I can't reproduce it on 5.0/i386, but I *can* on -current (5.99.59)
macppc:
g4:riz ~> env TZ=UTC sudo date 190201010000
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Wed Jan 1 00:00:00 UTC 1902
g4:riz ~> date
Tue Dec 31 16:00:01 PST 1901
g4:riz ~> sudo /etc/rc.d/ntpdate onestart
Setting date via ntp.
g4:riz ~> date
Wed Nov 24 09:29:25 PST 1875
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/13578
Date: Sat, 31 Dec 2022 03:16:10 +0000
On Sun, Jan 01, 2012 at 12:00:09AM +0000, Jeff Rizzo wrote:
> Ok, I can't reproduce it on 5.0/i386, but I *can* on -current (5.99.59)
> macppc:
>
> g4:riz ~> env TZ=UTC sudo date 190201010000
>
> We trust you have received the usual lecture from the local System
> Administrator. It usually boils down to these three things:
>
> #1) Respect the privacy of others.
> #2) Think before you type.
> #3) With great power comes great responsibility.
>
> Wed Jan 1 00:00:00 UTC 1902
> g4:riz ~> date
> Tue Dec 31 16:00:01 PST 1901
> g4:riz ~> sudo /etc/rc.d/ntpdate onestart
> Setting date via ntp.
> g4:riz ~> date
> Wed Nov 24 09:29:25 PST 1875
Observation: that time (in 1875) is the right time (for Dec 31, 2011)
with 0xffffffff pasted into the upper 32 bits.
After looking at the ntpdate code, which is ... interesting ..., I
strongly suspect a compiler bug, especially on a 32-bit target.
In which case there's a good chance it's no longer there, if anyone
has a macppc they don't mind messing with the clock on.
--
David A. Holland
dholland@netbsd.org
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/13578
Date: Sat, 31 Dec 2022 07:49:13 +0100
I just tried something similar on a macppc running -current (but
settimeofday will not allow me going before the epoch):
# date 196110100100
date: settimeofday: Invalid argument
# date 197110100100
Sun Oct 10 01:00:00 CET 1971
# ntpdate clock
31 Dec 07:47:57 ntpdate[1767]: step time server 192.168.111.42 offset +1616568460.952965 sec
# date
Sat Dec 31 07:48:27 CET 2022
Martin
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/13578
Date: Sat, 31 Dec 2022 23:38:54 +0000
On Sat, Dec 31, 2022 at 06:50:01AM +0000, Martin Husemann wrote:
> I just tried something similar on a macppc running -current (but
> settimeofday will not allow me going before the epoch):
>
> # date 196110100100
> date: settimeofday: Invalid argument
> # date 197110100100
> Sun Oct 10 01:00:00 CET 1971
> # ntpdate clock
> 31 Dec 07:47:57 ntpdate[1767]: step time server 192.168.111.42 offset +1616568460.952965 sec
> # date
> Sat Dec 31 07:48:27 CET 2022
Given that it was pasting 0xffffffff on, probably as a result of
having been in the previous epoch, that isn't conclusive.
On the other hand, if you can't set the date before the epoch at all
any more, that means the problem should be inaccessible even if it's
still live in ntpdate somewhere.
Which I think means we can close the PR. Unless we want to track down
the original problem further in case it _is_ a still-live compiler
bug. I admit I don't have much enthusiasm for that...
--
David A. Holland
dholland@netbsd.org
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 01 Apr 2023 19:46:46 +0000
State-Changed-Why:
Conclusion was to close the PR, no objections from passersby in the
past three months.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.