aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorLinus Torvalds2007-09-26 15:21:33 -0700
committerLinus Torvalds2007-09-26 15:43:41 -0700
commitf7f847b01571e86044dc77e03d92f43699652f8d (patch)
treefe5b32756facabc6aea9d354d6894efd809a47f9 /include
parentdf912ea4ae7233d1504fbd861ee127bd7ee5781d (diff)
Revert "x86-64: Disable local APIC timer use on AMD systems with C1E"
This reverts commit e66485d747505e9d960b864fc6c37f8b2afafaf0, since Rafael Wysocki noticed that the change only works for his in -mm, not in mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken on his hardware, but that's apparently not a regression, just a symptom of the same issue that causes the automatic apic timer disable to not work). It turns out that it really doesn't work correctly on x86-64, since x86-64 doesn't use the generic clock events for timers yet. Thanks to Rafal for testing, and here's the ugly details on x86-64 as per Thomas: "I just looked into the code and the logic vs. noapictimer on SMP is completely broken. On i386 the noapictimer option not only disables the local APIC timer, it also registers the CPUs for broadcasting via IPI on SMP systems. The x86-64 code uses the broadcast only when the local apic timer is active, i.e. "noapictimer" is not on the command line. This defeats the whole purpose of "noapictimer". It should be there to make boxen work, where the local APIC timer actually has a hardware problem, e.g. the nx6325. The current implementation of x86_64 only fixes the ACPI c-states related problem where the APIC timer stops in C3(2), nothing else. On nx6325 and other AMD X2 equipped systems which have the C1E enabled we run into the following: PIT keeps jiffies (and the system) running, but the local APIC timer interrupts can get out of sync due to this C1E effect. I don't think this is a critical problem, but it is wrong nevertheless. I think it's safe to revert the C1E patch and postpone the fix to the clock events conversion." On further reflection, Thomas noted: "It's even worse than I thought on the first check: "noapictimer" on the command line of an SMP box prevents _ONLY_ the boot CPU apic timer from being used. But the secondary CPU is still unconditionally setting up the APIC timer and uses the non calibrated variable calibration_result, which is of course 0, to setup the APIC timer. Wreckage guaranteed." so we'll just have to wait for the x86 merge to hopefully fix this up for x86-64. Tested-and-requested-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include')
-rw-r--r--include/asm-x86_64/apic.h1
1 files changed, 0 insertions, 1 deletions
diff --git a/include/asm-x86_64/apic.h b/include/asm-x86_64/apic.h
index e4580203dde2..85125ef3c414 100644
--- a/include/asm-x86_64/apic.h
+++ b/include/asm-x86_64/apic.h
@@ -20,7 +20,6 @@ extern int apic_verbosity;
extern int apic_runs_main_timer;
extern int ioapic_force;
extern int apic_mapped;
-extern int disable_apic_timer;
/*
* Define the default level of output to be very little