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

[Sepherosa Ziehau <sepherosa@xxxxxxxxx>]

On Tue, May 5, 2009 at 11:59 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>
> :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

The glitch will not be big, if we could save it just before entering
Sx state, I would expect no more than dozens of ticks.

>    TCP timeouts, for example.  Poor dntpd will also not be able to

I don't know whether things like TCP connections are still suppose to
work after Sx transition, since for Sx (x>=1), CPUs will not execute
instructions.

>    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.

The HPET document says it is not expected to work properly in Sx (x>=1) states.

>
>    As long as the maximum sleep time is not more then 1/36 of a

Well, I think you probably could expect a box staying in Sx state for
more than an hour :).  So except for saving/restoring timer's counter,
there are probably more things to do...

Best Regards,
sephe

-- 
Live Free or Die