[tip:x86/urgent] x86: Fix double enable_IR_x2apic() call on SMP kernel on !SMP boards

From: tip-bot for Suresh Siddha
Date: Fri Apr 02 2010 - 15:15:07 EST

Commit-ID: 472a474c6630efd195d3738339fd1bdc8aa3b1aa
Gitweb: http://git.kernel.org/tip/472a474c6630efd195d3738339fd1bdc8aa3b1aa
Author: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
AuthorDate: Wed, 31 Mar 2010 18:04:47 -0700
Committer: Ingo Molnar <mingo@xxxxxxx>
CommitDate: Fri, 2 Apr 2010 20:48:47 +0200

x86: Fix double enable_IR_x2apic() call on SMP kernel on !SMP boards

Jan Grossmann reported kernel boot panic while booting SMP
kernel on his system with a single core cpu. SMP kernels call
enable_IR_x2apic() from native_smp_prepare_cpus() and on
platforms where the kernel doesn't find SMP configuration we
ended up again calling enable_IR_x2apic() from the
APIC_init_uniprocessor() call in the smp_sanity_check(). Thus
leading to kernel panic.

Don't call enable_IR_x2apic() and default_setup_apic_routing()
from APIC_init_uniprocessor() in CONFIG_SMP case.

NOTE: this kind of non-idempotent and assymetric initialization
sequence is rather fragile and unclean, we'll clean that up
in v2.6.35. This is the minimal fix for v2.6.34.

Reported-by: Jan.Grossmann@xxxxxxxxxxx
Signed-off-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
Cc: <jbarnes@xxxxxxxxxxxxxxxx>
Cc: <david.woodhouse@xxxxxxxxx>
Cc: <weidong.han@xxxxxxxxx>
Cc: <youquan.song@xxxxxxxxx>
Cc: <Jan.Grossmann@xxxxxxxxxxx>
Cc: <stable@xxxxxxxxxx> # [v2.6.32.x, v2.6.33.x]
LKML-Reference: <1270083887.7835.78.camel@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
arch/x86/kernel/apic/apic.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 00187f1..e5a4a1e 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1640,8 +1640,10 @@ int __init APIC_init_uniprocessor(void)

+#ifndef CONFIG_SMP

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/