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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/