Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Len Brown]

On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
> 
> On Tue, 27 Mar 2007, Len Brown wrote:
> > 
> > I think the only fool-proof way to do this automatically is to
> 
> Why not just take the known-good CPUID signature?
>
> Screw firmware or ACPI tables. They're going to be occasionally wrong.
> 
> If we know that "Core 2, version X" has a good local APIC timer, we use 
> it. Otherwise we don't.
> 
> That's generally how we handle other APIC bugs too (the read-after-write 
> thing, for example, or the differences between integrated and off-chip 
> APIC's). Sometimes we check the APIC version itself, sometimes we check 
> the CPUID information, and sometimes we check both ("modern_apic()").

Yep, this is what we tried to do last week.
It failed, and the patch was reverted.

I agree, the BIOS vendor can lie with ACPI tables.
In particular, they can map any hardware C-state
to any ACPI C-state. Our expectation that they
would not map hardware C3 to ACPI C2
appears at this point to have been invalid.

So, speaking for Intel parts, every single one that supports
HW C3 from the beginning of history through today has a broken
LAPIC timer.  (and a few listed in that patch are known to
be broken in HW C2)   If we can't guarantee that the BIOS vendor
will not map that broken HW C3 to ACPI C2 (or even C1 via SMM)
then we have to not use the LAPIC timer except for systems with
a "known-good" signature = "part supports only C1".

If we really care about using the LAPIC timer on systems with deeper
than C1 support, the only alternative seems to be to test
if it actually works or not at boot and run-time.
Otherwise, we wait for future hardware with guaranteed
not to break under any (BIOS) conditions ships, and check for that.

Based on what I read of the HP nx6325 where the LAPIC timer
is breaking C1, AMD is in the same boat.

-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/