Handle disabled local apic better

When a kernel is compiled with local and io apic code, but the local APIC is disabled before ACPI starts ACPI gets confused. The situation can occur in a mainline kernel too, e.g. when a dmi_scan entry disables the local apic early.

The problem is that the ACPI code will do all the setup assuming there is a IO-APIC because the IO-APIC is not disabled, but the machine really runs in PIC mode. This usually leads to lost network (devices get an unreachable interrupt) or IDE hangs or other problems.

This patch adds checks for local apic enabled to all paths that need it (basically everybody who has a #ifdef CONFIG_X86_LOCAL_APIC needs this check instead)

It just handles the case there the up apic is disabled before ACPI boot, it can actually be disabled later too (e.g. when the APIC initialisation fails). This is probably still broken.

Also removes an bogus error message - this path can trigger just with software disabled APIC.

-Andi

diff -u linux/arch/i386/kernel/acpi/boot.c-o linux/arch/i386/kernel/acpi/boot.c

arch/i386/kernel/acpi/boot.c renamed from arch/i386/kernel/acpi/boot.c-o +0 -0

@@ -685,6 +685,13 @@
 #ifdef CONFIG_X86_LOCAL_APIC
 	int count, error;

arch/i386/kernel/apic.c renamed from arch/i386/kernel/apic.c-o +3 -2

 static void apic_pm_activate(void);
 
 void __init apic_intr_init(void)

@@ -190,6 +192,9 @@
 {
 	unsigned long value;
 
+	if (enable_local_apic < 0) 
+		return;
+
 	clear_local_APIC();
 
 	/*

@@ -1172,8 +1193,6 @@
 	 * Complain if the BIOS pretends there is one.
 	 */
 	if (!cpu_has_apic && APIC_INTEGRATED(apic_version[boot_cpu_physical_apicid])) {
-		printk(KERN_ERR "BIOS bug, local APIC #%d not detected!...\n",
-			boot_cpu_physical_apicid);
 		return -1;
 	}
 

diff -u linux/arch/i386/kernel/setup.c-o linux/arch/i386/kernel/setup.c

arch/x86_64/kernel/apic.c renamed from arch/x86_64/kernel/apic.c-o +1 -0

 /*
  * This initializes the IO-APIC and APIC hardware if this is

@@ -1009,12 +1010,14 @@
 
 static __init int setup_disableapic(char *str) 
 { 
+	enable_local_apic = -1;

Quoted 10 lines · Andi Kleen

When a kernel is compiled with local and io apic code, but the local APIC is disabled before ACPI starts ACPI gets confused. The situation can occur in a mainline kernel too, e.g. when a dmi_scan entry disables the local apic early.

The problem is that the ACPI code will do all the setup assuming there is a IO-APIC because the IO-APIC is not disabled, but the machine really runs in PIC mode. This usually leads to lost network (devices get an unreachable interrupt) or IDE hangs or other problems.

Quoted 3 lines

This patch adds checks for local apic enabled to all paths that need it (basically everybody who has a #ifdef CONFIG_X86_LOCAL_APIC needs this check instead)

oof, and there are lots of CONFIG_X86_LOCAL_APIC uses apparently un-guarded at run-time...

Looks like i386 lacks the parse_cmdline_early() check for "nolapic" to make this test effective.

(why the heck is the parse_args() so late, anyway?)

Looks like x86_64 has it, but then does it again at __setup() time -- which should probably be removed; along with the redundant variable "disable_apic".

Quoted 6 lines

diff -u linux/arch/i386/kernel/apic.c-o linux/arch/i386/kernel/apic.c

arch/i386/kernel/apic.c renamed from arch/i386/kernel/apic.c-o +0 -0

@@ -41,6 +41,8 @@
 

arch/i386/kernel/apic.c line 45

Quoted 4 lines

arch/i386/kernel/apic.c renamed from arch/i386/kernel/apic.c-o +2 -0

 #include "io_ports.h"
 
+extern int enable_local_apic;
+

how about declare in asm/apic.h instead?

Quoted 6 lines

arch/i386/kernel/apic.c renamed from arch/i386/kernel/apic.c-o +0 -0

 /* This value is set up by the early boot code to point to the value
    immediately after the boot time page tables.  It contains a *physical*
    address, and must not be in the .bss segment! */

@@ -917,6 +925,7 @@
 	acpi_reserve_bootmem();
 #endif

arch/i386/kernel/apic.c line 931

Quoted 5 lines

arch/i386/kernel/apic.c renamed from arch/i386/kernel/apic.c-o +1 -0

 #ifdef CONFIG_X86_FIND_SMP_CONFIG
+	if (enable_local_apic >= 0) 
 	/*
 	 * Find and reserve possible boot-time SMP configuration:
 	 */

Here we're disabling MPS with "nolapic" -- something that "maxcpus=0" and "nosmp" never effectively did before...

Quoted 12 lines

/*
* This initializes the IO-APIC and APIC hardware if this is

arch/i386/kernel/apic.c renamed from arch/i386/kernel/apic.c-o +1 -0

@@ -1009,12 +1010,14 @@
 
 static __init int setup_disableapic(char *str) 
 { 
+	enable_local_apic = -1;
 	disable_apic = 1;
 	return 0;
 } 
 

arch/i386/kernel/apic.c line 1023

Quoted 6 lines

arch/i386/kernel/apic.c renamed from arch/i386/kernel/apic.c-o +1 -0

 static __init int setup_nolapic(char *str) 
 { 
+	enable_local_apic = -1;
 	disable_apic = 1;
 	return 0;
 } 

these routines should be deleted, since they duplicate the earlier parse_cmdline_early(). the ambiguous "disable_lapic" should go also, since "enable_local_apic" is on the scene, yes?

BTW if that is all cleaned up I would suggest just to get rid of the CONFIGs and always use runtime defaults. This would make these parts more maintainable I think and is the right thing to do for distributions.

Quoted 2 lines

Here we're disabling MPS with "nolapic" -- something that "maxcpus=0" and "nosmp" never effectively did before...

MPS without local APIC is useless.

Quoted 11 lines

Quoted 11 lines

/*
* This initializes the IO-APIC and APIC hardware if this is

arch/x86_64/kernel/apic.c renamed from arch/x86_64/kernel/apic.c-o +1 -0

@@ -1009,12 +1010,14 @@
 
 static __init int setup_disableapic(char *str) 
 { 
+	enable_local_apic = -1;
 	disable_apic = 1;
 	return 0;
 } 
 

Quoted 10 lines

arch/x86_64/kernel/apic.c line 1023

Quoted 6 lines

arch/x86_64/kernel/apic.c renamed from arch/x86_64/kernel/apic.c-o +1 -0

 static __init int setup_nolapic(char *str) 
 { 
+	enable_local_apic = -1;
 	disable_apic = 1;
 	return 0;
 } 

these routines should be deleted, since they duplicate the earlier parse_cmdline_early(). the ambiguous "disable_lapic" should go also, since "enable_local_apic" is on the scene, yes?

No, even when you parse in parse_cmdline_early() you need a __setup, otherwise the normal __setup parser will complain about unknown options.

Quoted 4 lines

Quoted 2 lines

Here we're disabling MPS with "nolapic" -- something that "maxcpus=0" and "nosmp" never effectively did before...

MPS without local APIC is useless.

I agree, my point is that "nosmp" and "maxcpus=0" are broken in that they didn't disable MPS this early.

Quoted 3 lines

No, even when you parse in parse_cmdline_early() you need a __setup, otherwise the normal __setup parser will complain about unknown options.

Huh? So if I boot a kernel with an unknown parameter, say "len=gone_fishing", where would I expect to see the complaint -- I don't see it in my dmesg except where the entire commmand line is dumped out.

Quoted 7 lines

Quoted 3 lines

No, even when you parse in parse_cmdline_early() you need a __setup, otherwise the normal __setup parser will complain about unknown options.

Huh? So if I boot a kernel with an unknown parameter, say "len=gone_fishing", where would I expect to see the complaint -- I don't see it in my dmesg except where the entire commmand line is dumped out.

That will result in a environment variable len in init's environment with value gone_fishing and is not unknown. But nolapic doesn't have a =

Looks like i386 lacks the parse_cmdline_early() check for "nolapic" to make this test effective.