DragonFly-2.3.0.864.gc5b83 master sys/platform/pc32/apic mpapic.c sys/platform/pc32/isa clock.c sys/platform/pc64/isa clock.c sys/platform/vkernel/platform systimer.c sys/sys systimer.h

[Sepherosa Ziehau]

On Sun, May 3, 2009 at 1:42 AM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
> :It's not so simple. There is a problem when using deep sleep states in
> :modern CPU's (C3 and deeper) - lapic timer is stopped when CPU enters
> :into C3. And using C3 (or even C4) is obviously completely normal thing
> :to do in laptops.
> :
> :See these commits for more pointers/details:
> :
> :http://permalink.gmane.org/gmane.os.freebsd.devel.cvs.src/105079
> :http://lists.xensource.com/archives/html/xen-changelog/2008-05/msg00221.html
> :http://bugzilla.kernel.org/show_bug.cgi?id=2560
> :
> :--
> :Hasso Tepper
>
>    Hmm.  The "lapic timer: Correct AMD C1E handling" commit doesn't
>    fix that issue?

It is AMD only.  AMD's multi-core CPU does not seem to be able enter
C2/C3 state, so AMD seem to invent C1E which is similar to C3.

>
>    The cool thing about our systimers is that we do not use the
>    systimer hardware itself to calculate elapsed time, we just use
>    it as a one-shot.  We use sys_cputimer (typically the ACPI or HPET)
>    for elapsed time.
>
>    This means the lapic timer *CAN* be temporarily disabled,
>    just as long as some interrupt somewhere comes along at some
>    point to wake the machine up, on every cpu that is in a sleep
>    state.
>
>    We would want to ensure that the sleep state is not held more then
>    a millisecond or two, otherwise network polling and other very
>    fast systimer events will not go as fast as expected.  Slower
>    systimer events such as the seconds timer and scheduler (100hz)
>    are not as big an issue as long as the wakeup occurs in a
>    reasonable period of time (aka < 10ms).
>
>    If the lapic timer is disabled we clearly cannot depend on
>    it to wake the machine up, so we might need some sort of
>    fail-safe interrupt for that... maybe the 8254 can still
>    be used for that purpose, or the RTC real time clock
>    interrupt that we use for profiling.  This interrupt would
>    have to send a dummy IPI to every cpu on the system.

Switch one shot timer is quite simple now, since cputimer_intr_reload
is function pointer :)

Best Regards,
sephe

-- 
Live Free or Die