DragonFly commits List (threaded) for 2009-05
Re: DragonFly-184.108.40.2066.g136cd master sys/dev/acpica5 acpi_hpet.c
:No, not the actual count, but we will have to make sure the count is
:monotonically increasing. So something like "not preserved" is not
:> has to be reprogrammed after S3/S4 or at least recomputed by the code
:> that reads back the RTC value.
:Didn't aware how 8254 could be affected, 8254 document mentions
:nothing about power management stuffs. But even if 8254's count is
:not maintained at all, it seems to be less affected (+-1/15sec), since
:major portion of the time is saved in dram.
:If small gitch is acceptable, we could just add sys_cputimer
:save/restore functions and call them before and after Sx state
:Live Free or Die
No, the actual timekeeping function cannot glitch. It is not
acceptable. It will really mess up all sorts of things in the
system even if it is just a forwards monotonic jump. Things like
TCP timeouts, for example. Poor dntpd will also not be able to
keep the time synchronized.
Is there a way to know for sure whether a sleep state messes
up the HPET? It sounds like it would be messy but it might be
possible to use the 8254's free-running timer (our last-chance
systimer) to check that the HPET is still functioning after
a sleep state exits. If their approximate relative times do not
match then then we will know that the HPET is being messed up
by the sleep state.
As long as the maximum sleep time is not more then 1/36 of a
second then comparing relative time values between the two
free-running timers is viable. The 8254 rolls over in 1/18
second but for a relative comparison it cannot have progressed
more the half way, to be safe.