svn commit: r302782 - in head/sys: dev/acpica i386/isa

[Bruce Evans]

On Wed, 13 Jul 2016, Jung-uk Kim wrote:

> Log:
>  Remove a tunable and always reset system clock while resuming with ACPI.
>
>  Requested by:	bde (long ago)

Thanks.

> Modified:
>  head/sys/dev/acpica/acpi.c
>  head/sys/i386/isa/pmtimer.c

This also prevents the reset by pmtimer if acpi is active.  This leaves
pmtimer doing nothing if acpi is active.  pmtimer is supposed to do a
much more complete reset (reset more accurately, and fix up callouts),
but the callout code has not compiled since before it was committed.  It
is too broken to have ever been in conf/options* or conf/NOTES, so this
bug is not normally noticed.

i386 with acpi should be work without pmtimer now.  Non-{amd64,i386} with
acpi but with pmtimer non implemented might work now.

pmtimer is in i386's GENERIC, but this is probably not needed now

When the clock is not reset on resume, the system time is off by about
the length of the suspension.  It can be reset from userland using much
the same sequence as for booting, except the error will be larger so
more forceful stepping is required (kill ntpd and then use ntpdate;
submit a bug report if the threatened removal of ntpdate is implemented).
The large step from this is harmful to running programs and is better
done in the kernel before letting them run, but letting them run before
the step is harmful, and doing this in userland at least gets the step
right.  The standard /etc/resume script is clueless about this (and
about almost everything -- it is empty except for about 2 hints for
old hardware.  An active ntpd is also clueless about such large steps,
at least for the old version that I use.

When the clock is reset by pmtimer on resume, the system time is off by
about 0-1 seconds plus the drift of the RTC while suspended.

When the clock is reset by pmtimer on resume, the system time is off by
about 0-2 seconds plus the drift of the RTC while suspended.

The extra accuracy provided by pmtimer is not very useful, since an error
of more than a few milliseconds is enough to confuse ntpd, at least for
the old version of ntpd that I use.  Smaller errors are actually more
harmful unless they are fairly small, since ntpd will slew the clock for
all errors.  I used to use -x to force it to slew the clock for all errors.
This is worse than useless for recovery after suspension.  A documented,
it takes 14 days to recover from an error of just 600 seconds.  In the
old version, it was not limited to 600 seconds.  It was also broken (it
competed with the kernel part of itself to slew the clock, and made a
mess), but I fixed that.  In the current version, it is limited to 600
seconds and the fix is apparently to turn off the kernel time discipline.
So I no longer use -x.  This didn't work for long suspends either.  ntpd
was confused and aborted because the necessary step was considered
preposterous.  I can't find the threshold for this.  Initially it is 900
seconds.

Long callouts are also broken by suspensions.  E.g., "sleep 86400" sleeps
for 1 day plus the accumulated suspension time, not for 1 day as specified,
because its misimplemented using something like a callout.  If callouts
worked then the error would be limited to the accumulated leap seconds
adjustment.  The uncompilable code in pmtimer tries to fix this.  This
has nothing to do with pmtimer, except that the error is largest after
suspension and the KPI doesn't allow telling upper layers to do it for
only some clock adjustments.

Bruce