Subject: Re: todr changes to improve clock accuracy across sleeps & reboots
To: Perry E. Metzger <perry@piermont.com>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 09/08/2006 11:39:18
--ibhTSt8h7StI2D+z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 07, 2006 at 09:17:33PM -0400, Perry E. Metzger wrote:
> The system clock is often being conditioned by something like NTP. The
> reason for writing back the RTC when a change in the system clock
> happens or another event that triggers resettodr is to assure that
> they stay in sync so the next reboot gets the benefit of whatever is
> conditioning the clock.

So, in the normal case (shutdown aside), todr resets should be
scheduled and actually done in a callout (or similar) that happens as
close as possible to the second boundary.

For the shutdown case, the question becomes whether to wait for that
to have run before callout processing is stopped.  That could be an
option/sysctl.  If the reset is scheduled early enough in the
shutdown/suspend routine, there's a reasonable chance it will have run
anyway by the time other things (like unmounting/quiescing
filesystems, saving driver state, etc) have happened.

And, by Richard's argument, it doesn't really matter if it hasn't as
long as updates have happened recently enough during normal running.

Which really just leaves the question of how to align with second
transition at startup. =20

--
Dan.

--ibhTSt8h7StI2D+z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)

iD8DBQFFAMnFEAVxvV4N66cRAmDfAJ9sAaIbqG/Tf+pRn/BAQ5W0uI2KNwCfZQ0y
cPc4hsfvaxCXPluEF6dzlz4=
=Sw44
-----END PGP SIGNATURE-----

--ibhTSt8h7StI2D+z--