On Fri, 14 Dec 2007 13:20:48 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > AMD doesn't support states deeper than C1 on multi core currently, so > in general they don't matter much right now. Thanks for the info, I wasn't aware of this.
> The better solution there is to use HPET instead. Newer systems > generally have HPET already enabled in the BIOS and for older systems > hpet=force gains more and more support. So try that. Dynticks won't use the HPET, even if enabled. IIRC, HPET is enabled on my system (NVIDIA MCP51) even without "hpet=force". Here's dmesg's output on Linux 2.6.24-rc5: $ dmesg | grep -Ei "(lapic|hpet|disabling)"Command line: ro hpet=force ACPI: HPET 3FFA9730, 0038 (r1 A M I OEMHPET0 2000727 MSFT 97) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: HPET id: 0x10de8201 base: 0xfed00000 Kernel command line: ro hpet=force hpet clockevent registered TSC calibrated against HPET Disabling APIC timer hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31 hpet0: 3 32-bit timers, 25000000 Hz Time: hpet clocksource has been installed. Clockevents: could not switch to one-shot mode: lapic is not functional. Clockevents: could not switch to one-shot mode: lapic is not functional. Unpacking initramfs...<6>Clockevents: could not switch to one-shot mode:<6>Clockevents: could not switch to one-shot mode: lapic is not functional. lapic is not functional. hpet_resources: 0xfed00000 is busy LAPIC is seemingly disabled (C1E detection code does this), but clockevents still tries to use it, instead of relying on HPET. I'll look into this, but please give me a heads up if you know more about what's happening. Looks like fixing this is better than using LAPIC for dynticks (and disabling C1E) on such systems. -- 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/
