Re: 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 <sepherosa@xxxxxxxxx>]

On Sun, May 3, 2009 at 2:37 AM, Hasso Tepper <hasso@estpak.ee> wrote:
> Matthew Dillon wrote:
>>     Hmm.  The "lapic timer: Correct AMD C1E handling" commit doesn't
>>     fix that issue?
>
> AFAICS nope.

Yeah, its AMD only stuff.

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

Linux auto-detects C3 capable CPU and use i8254 and boardcast IPI to
other CPUs, FreeBSD just skip the C3 capability detection rest is
same.  (we actually use i8254 and boardcast IPI for ~5 years :)

Because of the well designed systimer_intr processing, we could
actually switch the one shot timer on a running system!  Though I
don't have a system that could do C3 testing, I added a sysctl to test
the dynamic switching.  It works as expected.

So the dragonfly's way for C3 is:
1) Always register clk for i8254
2) If ->C3, use i8254.  If C3->, use lapic timer.

Please see:
76c58571c167a68b12478dcff753f0a639e381da
6db20215894051960ac519131925a023a173b51d

Well, as about the clk registering, I am about to add a tunable to
disable it.  On one of my boxes, there are alway 18/s interrupts on
IRQ0 :(, and the box actually does not care about C3 state.

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

Well, HPET's one shot timer is programmatic sucks, IMHO.  And on
system with broken ACPI tables (one of my boxes), you could not access
the register space beyond main counter.

Best Regards,
sephe

-- 
Live Free or Die