Messages in this thread | | | Date | Fri, 3 Nov 2006 01:06:31 +0100 | From | Andreas Mohr <> | Subject | Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1] |
| |
Hi,
[CC'd Len since he might want/be able to help despite this being VIA issue ;)]
On Thu, Nov 02, 2006 at 09:34:30PM +0100, Andreas Mohr wrote: > This time with apic=debug (attached), and now we have messages such as: > > lapic timer verify: delta 10754906 pmtimer 11935676 (2557644) lapic 1180770(0 1180770 1180807) on cpu 0 > > which means that the timer *is* unstable. > > I'm starting to wonder what I could debug here...
OK, I debugged it some more, and I noticed some very strange ACPI status again...
$ cat /proc/acpi/processor/CPU0/* processor id: 0 acpi id: 0 bus mastering control: no power management: no throttling control: no limit interface: no <not supported> active state: C0 max_cstate: C8 bus master activity: 00000000 maximum allowed latency: 2000 usec states: <not supported>
HOWEVER (dmesg.log.gz):
ACPI: CPU0 (power states: C1[C1] C2[C2])
and
ACPI: lapic on CPU 0 stops in C2[C2]
So according to /proc/acpi/ I don't even *have* C1/C2, however it's still being used.
Oh, wait, I just realized that of course I'm in 2.6.19-rc1-mm1 currently, however booting into 2.6.19-rc4-mm1 *does* list C1/C2 states in /proc/acpi/, in contrast to -rc1-mm1. That would explain why 2.6.19-rc1-mm1 has no issues whatsoever with dynticks - since it never even enters C1/C2!
OK, so dynticks in Linux > 2.6.19-rc1-mm1 broke because ACPI C1/C2 suddenly became available which killed my VIA APIC timer in C2.
How probable is it that the APIC timer got killed due to mis-programming in Linux versus VIA chipset design garbage probability? I.e. do you think there's a chance to fix C2 malfunction by going into the innards of VIA chipsets operation? How useful would it be to simply disable C2 operation (but not C1) in CONFIG_NO_HZ mode after's been determined to kill APIC timer?:
lapic timer verify: delta 3435285 pmtimer 3469523 (743469) lapic 34238(0 34238 3 4338) on cpu 0 lapic timer verify: delta 6022 pmtimer 46853 (10040) lapic 40831(0 40831 40914) on cpu 0 lapic timer verify: delta 66814 pmtimer 136000 (29143) lapic 69186(0 69186 69284 ) on cpu 0 lapic timer verify: delta 19658 pmtimer 22092 (4734) lapic 2434(0 2434 2469) on cpu 0 lapic timer verify: delta 9967 pmtimer 22624 (4848) lapic 12657(0 12657 12693) o n cpu 0 lapic timer verify: delta 9681 pmtimer 21429 (4592) lapic 11748(0 11748 11945) o n cpu 0 lapic timer verify: delta 59879 pmtimer 94822 (20319) lapic 34943(0 34943 35029) on cpu 0 lapic timer verify: delta 34878 pmtimer 52668 (11286) lapic 17790(0 17790 17876) on cpu 0 lapic timer verify: delta 32436 pmtimer 78992 (16927) lapic 46556(0 46556 46641) on cpu 0 lapic timer verify: delta 10450 pmtimer 75002 (16072) lapic 64552(0 64552 64590) on cpu 0 ACPI: lapic on CPU 0 stops in C2[C2]
Hmm, processor_idle.c in current -dynticks4 seems to contain code to do just that: disable C states after they've been found harmful to timer operation? But somehow it doesn't seem to work for me here, obviously. If I don't get any further input on that I'll try to debug it myself soon.
http://www.linuxsymposium.org/proceedings/reprints/Reprint-Brown-OLS2004.pdf is quite informative about APIC timer issues etc., BTW.
Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |