DragonFly commits List (threaded) for 2009-05
Re: DragonFly-18.104.22.1684.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
: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:
Hmm. The "lapic timer: Correct AMD C1E handling" commit doesn't
fix that issue?
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
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.
Does the ACPI code itself have some sort of sleep timeout
that can be set? If so we can use that to do the required