Re: DragonFly-2.3.0.876.g136cd master sys/dev/acpica5 acpi_hpet.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:No, not the actual count, but we will have to make sure the count is
:monotonically increasing.  So something like "not preserved" is not
:acceptable.
:
:> 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
:transiton.
:
:-- 
: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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>