https://bugzilla.novell.com/show_bug.cgi?id=441106
User mmeeks@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=441106#c14
Michael Meeks changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
Info Provider|garloff@novell.com |
--- Comment #14 from Michael Meeks 2008-11-20 04:26:17 MST ---
Hi Werner. I guess Kurt forgot to attach an actual patch to boot.clock instead
of a description, which (when read with the patches) of course helps explain
how this works. As I understand it you need:
/sbin/hwclock --preadjust --nowait --hctosys $HWCLOCK
This does the adjustment to the hwclock of the potentially long time powered
off we've just had. *But* it does not write to /etc/adjtime. OTOH it guarentees
that we are early, by around 1-2 seconds.
This lets us get on with the boot process - while the other patches clearly
allow a far less CPU intensive, intelligent and (hopefully accurate) catch of
the hwclock edge - and the re-run of:
/sbin/hwclock --adjust --hctosys $HWCLOCK 2>&1 &
Is conceptually identical (yet more efficient) to the previous behaviour of the
two commands in boot.clock - and allows the boot to continue - it will give us
just as an accurate adjtime setting, and - it will only move the time
'forwards' (ie. still monotomically increasing) well, where is the problem ?
So - basically, this looks bullet-proof to me, saves us an embarassing chunk of
time at boot, is just as accurate, and is - well, just the right thing to do -
Kurt: you rock :-)
Werner - can you expand on the problem with the root file-system mount; I
didn't get that: do we do some magic & copying over of adjtime later in the day
after re-mounting the root (or somesuch ?).
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.