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:

Home	PR Database Search