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

[Hasso Tepper]

Matthew Dillon wrote:
>     Hmm.  The "lapic timer: Correct AMD C1E handling" commit doesn't
>     fix that issue?

AFAICS nope.

I'm afraid that I don't know enough about the topic to discuss details. 
All I know that I had a problems with my laptop and Linux and it was 
fixed at some point.

http://bugzilla.kernel.org/show_bug.cgi?id=2560 has all details how it was 
solved in Linux - the comment #12 has link to the explanation and some 
comments later there are patches as well.

In FreeBSD these commits are relevant (during last two days, btw):

http://permalink.gmane.org/gmane.os.freebsd.devel.cvs.src/105079
http://permalink.gmane.org/gmane.os.freebsd.devel.cvs.src/105086
http://permalink.gmane.org/gmane.os.freebsd.devel.cvs.src/105100

I don't have exact pointers how Solaris solved the problem. Quick googling 
gave me this though:

http://opensolaris.org/os/project/tesla/Work/CPUPM/

"Solaris uses the local APIC timer to generate interrupts for the Cyclic 
Backend (CBE). The lAPIC timer in a CPU may stop counting and will not 
generate interrupts while the processor is in ACPI states C2 and C3. 
Ongoing work is being done to use the High Precision Event Timer (HPET) 
as a proxy for stalled lAPIC timers. The HPET is located on the chipset 
isolated from CPU C-State power side effects. CPU must schedule their 
next CBE interrupt on the HPET when they enter a deep C-state."


-- 
Hasso Tepper