From owner-freebsd-hackers  Mon Jul 17 00:37:56 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id AAA09580
          for hackers-outgoing; Mon, 17 Jul 1995 00:37:56 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA09545
          for <hackers@freebsd.org>; Mon, 17 Jul 1995 00:37:37 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA23493; Mon, 17 Jul 1995 17:33:39 +1000
Date: Mon, 17 Jul 1995 17:33:39 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507170733.RAA23493@godzilla.zeta.org.au>
To: mpp@legarto.minn.net, terry@cs.weber.edu
Subject: Re: FS root mount handling discrepancy
Cc: bde@zeta.org.au, hackers@freebsd.org
Sender: hackers-owner@freebsd.org
Precedence: bulk

>Each *_mountroot routine should call inittodr, since that routine
>is used to establish the system clock from the real time clock
>at boot time.  The argument to inittodr is the value the clock is set 
>to if the RTC cannot be read for some reason.  

I think inittodr() should be called much earlier.  It doesn't need a
root file system to work on systems with a suitable clock.

>Something else interesting I noticed was the the APM routines call
>inittodr to reset the system clock to the RTC after a resume
>from a suspend, however they call it with a value of zero.
>No big deal, but on the off chance that the RTC somehow died
>during that interval, the time would warp back to 1/1/70.
>Probably calling it with something like:
>	inittodr(time.tv_sec)
>would be better, since the clock would just start again from 
>its last setting before the suspend.

It should probably do this if its arg is 0 or -1.

Bruce