> I've been thinking about a bunch of ways to fix this nit, but most of
> them involve spinning for up to one second, which isn't really a good
> idea. I was therefore wondering if people on tech-kern had any
> opinions on the "correct" method.

Someone to whom near-microsecond accuracy is truly important might well
not begrudge a whole extra second in the boot process -- unless there is
some kind of device-initialization issue that could get fouled up.

A cheap way to fix it to HZ resolution would be to set the time lazily;
instead of initializing the in-memory time inline in the boot code to the
rounded second value, simply ensure that the clock interrupt code will
initialize the time the next interrupt which sees a different second value.
You could also combine the two ideas by setting the time very lazily:  the
clock interrupt code could be primed to watch for the second value changing,
and once it sees that transition, start a countdown:  the HZ-1'th next
clock interrupt will then spinwait for up to 1/HZ seconds waiting for the
second value to change, and set the time then.  (Possibly to avoid a race
you should trigger on the HZ-2'th next interrupt and be prepared to spinwait
for 2/HZ seconds -- potentially (usually) missing one clock interrupt.

A third alternative is to just ignore the problem:  if someone truly wants
sub-second time accuracy from the moment their system is booted, perhaps
they should be thinking dedicated hardware, not hoping there's enough layers
of software bandages over their 300ppm PC clock circuit...