[PATCH] leave APIC code inactive by default on i386

[PATCH] leave APIC code inactive by default on i386

[Darrick J. Wong]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

Hi there,

Some old i386 systems have flaky APIC hardware that doesn't always work
right.  Right now, enabling the APIC code in Kconfig means that the APIC
code will try to activate the APICs unless 'noapic nolapic' are passed
to force them off.  The attached patch provides a config option to
change that default to keep the APICs off unless specified otherwise,
disables get_smp_config if we are not initializing the local APIC, and
makes init_apic_mappings not init the IOAPICs if they are disabled.
Note that the current behavior is maintained if
CONFIG_X86_UP_APIC_DEFAULT_OFF=n.

This patch is particularly useful for anybody booting a distro UP kernel
on a multi-chassis IBM x440/x445, because that system requires APIC
support to boot properly.  If booting a UP kernel on a large SMP machine
seems silly, think of distro installer kernels. :)  Joe Flakybox can run
his single-proc i386 box without APIC related breakage, and someone with
a x445 enable APICs in the UP kernel long enough to install a proper SMP
kernel.

Most everybody else in the world can configure their UP kernel with
CONFIG_APIC=y/n as desired and ignore this patch.

I know, it seems silly to be providing a patch that changes "enabled
unless explicitly disabled" to "disabled unless explicitly enabled",
especially since the APIC code can be forced off.  However, I _am_
curious to hear what people think about the other parts of the patch.
At the very least, I'm not quite convinced that noapic & nolapic are
doing their jobs, because it seems to me that get_smp_config pokes the
LAPIC and init_apic_mappings maps the IOAPICs into memory regardless of
whatever flags are passed.  But, I'm not an APIC expert so I'll defer to
anybody who knows more than I.  Most curiously, passing 'noapic nolapic'
still yields things like this in dmesg:

"Enabling APIC mode:  Flat.  Using 1 I/O APICs"

FWIW, this has been tested on a Sun V40z, IBM x205, x226, x206m, x445,
x260, x366, x225, x336 and a dual-node x460 without problems.  A similar
patch has been lurking in Redhat Rawhide kernels for several months
without problems.

Questions?  Flames?  The asbestos underpants have been strapped on. :)

--D

And the usual stamp for said patch:

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>

[-- Attachment #2: iapic-kern_3.patch --]
[-- Type: text/x-patch, Size: 5980 bytes --]

diff -Naurp a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig	2006-01-04 15:18:21.000000000 -0800
+++ b/arch/i386/Kconfig	2006-01-19 14:33:33.000000000 -0800
@@ -253,6 +253,20 @@ config X86_UP_IOAPIC
 	  to use it. If you say Y here even though your machine doesn't have
 	  an IO-APIC, then the kernel will still run with no slowdown at all.
 
+config X86_UP_APIC_DEFAULT_OFF
+	bool "APIC support on uniprocessors defaults to off"
+	depends on !SMP && X86_UP_APIC
+	help
+	  Some older systems have flaky APICs.  Say Y to keep leave the APICs
+	  disabled by default, while still allowing them to be enabled by the
+	  "lapic" (local APIC) and "apic" (I/O APIC) command line options.
+	  Generally speaking, either you want to enable both types of APICs
+	  or none at all.
+
+	  Usually this is only necessary for distro installer kernels that
+	  must work with everything.  Everyone else can safely say N here
+	  and configure APIC support in or out as needed.
+
 config X86_LOCAL_APIC
 	bool
 	depends on X86_UP_APIC || ((X86_VISWS || SMP) && !X86_VOYAGER)
diff -Naurp a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
--- a/arch/i386/kernel/acpi/boot.c	2006-01-04 15:18:21.000000000 -0800
+++ b/arch/i386/kernel/acpi/boot.c	2006-01-19 14:17:50.000000000 -0800
@@ -37,6 +37,10 @@
 #include <asm/io.h>
 #include <asm/mpspec.h>
 
+#ifdef CONFIG_X86_32
+extern int enable_local_apic __initdata;
+#endif
+
 #ifdef	CONFIG_X86_64
 
 extern void __init clustered_apic_check(void);
@@ -807,6 +811,16 @@ static void __init acpi_process_madt(voi
 #ifdef CONFIG_X86_LOCAL_APIC
 	int count, error;
 
+#ifdef CONFIG_X86_32
+	if (enable_local_apic < 0) {
+		printk(KERN_INFO PREFIX "Local APIC disabled; pass 'lapic' "
+							"to re-enable.\n");
+		return;
+	}
+
+	printk(KERN_INFO PREFIX "Local APIC enabled.\n");
+#endif
+
 	count = acpi_table_parse(ACPI_APIC, acpi_parse_madt);
 	if (count >= 1) {
 
diff -Naurp a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c	2006-01-04 15:18:21.000000000 -0800
+++ b/arch/i386/kernel/apic.c	2006-01-19 14:21:24.000000000 -0800
@@ -42,8 +42,9 @@
 
 /*
  * Knob to control our willingness to enable the local APIC.
+ * -2=default-disable, -1=force-disable, 1=force-enable, 0=automatic
  */
-int enable_local_apic __initdata = 0; /* -1=force-disable, +1=force-enable */
+int enable_local_apic __initdata = (X86_APIC_DEFAULT_OFF ? -2 : 0);
 
 /*
  * Debug level
@@ -757,7 +758,7 @@ static int __init detect_init_APIC (void
 		 * APIC only if "lapic" specified.
 		 */
 		if (enable_local_apic <= 0) {
-			printk("Local APIC disabled by BIOS -- "
+			printk("Local APIC disabled by BIOS (or by default) -- "
 			       "you can enable it with \"lapic\"\n");
 			return -1;
 		}
@@ -839,7 +840,7 @@ void __init init_apic_mappings(void)
 		int i;
 
 		for (i = 0; i < nr_ioapics; i++) {
-			if (smp_found_config) {
+			if (smp_found_config && !skip_ioapic_setup) {
 				ioapic_phys = mp_ioapics[i].mpc_apicaddr;
 				if (!ioapic_phys) {
 					printk(KERN_ERR
@@ -1273,6 +1274,16 @@ int __init APIC_init_uniprocessor (void)
 		return -1;
 
 	/*
+	 * If local apic is off due to config_x86_apic_off option,
+	 * jump out here.
+	 */
+	if (enable_local_apic < -1) {
+		printk(KERN_INFO "Local APIC disabled by default; "
+					"use 'lapic' to enable it.\n");
+		return -1;
+	}
+
+	/*
 	 * Complain if the BIOS pretends there is one.
 	 */
 	if (!cpu_has_apic && APIC_INTEGRATED(apic_version[boot_cpu_physical_apicid])) {
diff -Naurp a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
--- a/arch/i386/kernel/io_apic.c	2006-01-04 15:18:21.000000000 -0800
+++ b/arch/i386/kernel/io_apic.c	2006-01-17 14:58:30.000000000 -0800
@@ -681,7 +681,7 @@ void fastcall send_IPI_self(int vector)
 #define MAX_PIRQS 8
 static int pirq_entries [MAX_PIRQS];
 static int pirqs_enabled;
-int skip_ioapic_setup;
+int skip_ioapic_setup = X86_APIC_DEFAULT_OFF;
 
 static int __init ioapic_setup(char *str)
 {
diff -Naurp a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c	2006-01-04 15:18:21.000000000 -0800
+++ b/arch/i386/kernel/setup.c	2006-01-19 14:23:38.000000000 -0800
@@ -60,6 +60,10 @@
 #include "setup_arch_pre.h"
 #include <bios_ebda.h>
 
+#ifdef CONFIG_X86_LOCAL_APIC
+extern int enable_local_apic __initdata;
+#endif
+
 /* Forward Declaration. */
 void __init find_max_pfn(void);
 
@@ -865,6 +869,10 @@ static void __init parse_cmdline_early (
 		/* disable IO-APIC */
 		else if (!memcmp(from, "noapic", 6))
 			disable_ioapic_setup();
+		/* enable IO-APIC */
+		else if (!memcmp(from, "apic", 4))
+			enable_ioapic_setup();
+
 #endif /* CONFIG_X86_IO_APIC */
 #endif /* CONFIG_ACPI */
 
@@ -1606,8 +1614,14 @@ void __init setup_arch(char **cmdline_p)
 #endif
 #endif
 #ifdef CONFIG_X86_LOCAL_APIC
-	if (smp_found_config)
-		get_smp_config();
+	if (smp_found_config) {
+		if (enable_local_apic >= 0) {
+			printk(KERN_INFO "LAPIC enabled.\n");
+			get_smp_config();
+		} else {
+			printk(KERN_INFO "LAPIC disabled.\n");
+		}
+	}
 #endif
 
 	register_memory();
diff -Naurp a/include/asm-i386/acpi.h b/include/asm-i386/acpi.h
--- a/include/asm-i386/acpi.h	2006-01-04 15:18:23.000000000 -0800
+++ b/include/asm-i386/acpi.h	2006-01-17 14:58:30.000000000 -0800
@@ -134,6 +134,10 @@ static inline void disable_ioapic_setup(
 {
 	skip_ioapic_setup = 1;
 }
+static inline void enable_ioapic_setup(void)
+{
+	skip_ioapic_setup = 0;
+}
 
 static inline int ioapic_setup_disabled(void)
 {
diff -Naurp a/include/asm-i386/apic.h b/include/asm-i386/apic.h
--- a/include/asm-i386/apic.h	2006-01-04 15:18:23.000000000 -0800
+++ b/include/asm-i386/apic.h	2006-01-17 14:58:30.000000000 -0800
@@ -82,6 +82,12 @@ int get_physical_broadcast(void);
 # define apic_write_around(x,y) apic_write_atomic((x),(y))
 #endif
 
+#ifdef CONFIG_X86_UP_APIC_DEFAULT_OFF
+# define X86_APIC_DEFAULT_OFF 1
+#else
+# define X86_APIC_DEFAULT_OFF 0
+#endif
+
 static inline void ack_APIC_irq(void)
 {
 	/*

Re: [PATCH] leave APIC code inactive by default on i386

[Jan Engelhardt]

>This patch is particularly useful for anybody booting a distro UP kernel
>on a multi-chassis IBM x440/x445, because that system requires APIC
>support to boot properly.  If booting a UP kernel on a large SMP machine
>seems silly, think of distro installer kernels. :)  Joe Flakybox can run
>his single-proc i386 box without APIC related breakage, and someone with
>a x445 enable APICs in the UP kernel long enough to install a proper SMP
>kernel.
>
>I know, it seems silly to be providing a patch that changes "enabled
>unless explicitly disabled" to "disabled unless explicitly enabled",
>especially since the APIC code can be forced off.  However, I _am_
>curious to hear what people think about the other parts of the patch.
>At the very least, I'm not quite convinced that noapic & nolapic are
>doing their jobs, because it seems to me that get_smp_config pokes the
>LAPIC and init_apic_mappings maps the IOAPICs into memory regardless of
>whatever flags are passed.  But, I'm not an APIC expert so I'll defer to
>anybody who knows more than I.  Most curiously, passing 'noapic nolapic'
>still yields things like this in dmesg:
>
>Questions?  Flames?  The asbestos underpants have been strapped on. :)

Do you think that people can't properly configure their bootloader to 
include "noapic nolapic" in the options?


Jan Engelhardt
-- 

Re: [PATCH] leave APIC code inactive by default on i386

[Michael Ellerman]

On 1/20/06, Darrick J. Wong <djwong@us.ibm.com> wrote:
> Hi there,
>
> Some old i386 systems have flaky APIC hardware that doesn't always work
> right.  Right now, enabling the APIC code in Kconfig means that the APIC
> code will try to activate the APICs unless 'noapic nolapic' are passed
> to force them off.  The attached patch provides a config option to
> change that default to keep the APICs off unless specified otherwise,
> disables get_smp_config if we are not initializing the local APIC, and
> makes init_apic_mappings not init the IOAPICs if they are disabled.
> Note that the current behavior is maintained if
> CONFIG_X86_UP_APIC_DEFAULT_OFF=n.

...

Did this hit the floor? It strikes me as a pretty good solution. This
is pretty nasty for newbies installing distro kernels, they get some
of the way through an install and then their machine just locks - not
good PR.

cheers

Re: [PATCH] leave APIC code inactive by default on i386

[Dave Jones]

On Wed, Mar 01, 2006 at 02:57:05PM +1100, Michael Ellerman wrote:
 > On 1/20/06, Darrick J. Wong <djwong@us.ibm.com> wrote:
 > > Hi there,
 > >
 > > Some old i386 systems have flaky APIC hardware that doesn't always work
 > > right.  Right now, enabling the APIC code in Kconfig means that the APIC
 > > code will try to activate the APICs unless 'noapic nolapic' are passed
 > > to force them off.  The attached patch provides a config option to
 > > change that default to keep the APICs off unless specified otherwise,
 > > disables get_smp_config if we are not initializing the local APIC, and
 > > makes init_apic_mappings not init the IOAPICs if they are disabled.
 > > Note that the current behavior is maintained if
 > > CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
 > Did this hit the floor?

It's still being kicked around.  I saw one patch off-list earlier this
week that has some small improvements over the variant originally posted,
but still had 1-2 kinks.

 > It strikes me as a pretty good solution. This
 > is pretty nasty for newbies installing distro kernels, they get some
 > of the way through an install and then their machine just locks - not
 > good PR.

The number of systems that actually *need* APIC enabled are in the
vast (though growing) minority, so it's unlikely that most newbies
will hit this.  The problem is also the inverse of what you describe.
Typically the distros have DMI lists of machines that *need* APIC
to make it enabled by default so everything 'just works'.

The big problem the patch solves is allowing it to be possible
to build a kernel with UP APIC code, but disabled by default
(Because there a lot of older machines that die horribly if it
 was enabled by default).

		Dave

Re: [PATCH] leave APIC code inactive by default on i386

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

On Wed, 1 Mar 2006 15:33, Dave Jones wrote:
> On Wed, Mar 01, 2006 at 02:57:05PM +1100, Michael Ellerman wrote:
>  > On 1/20/06, Darrick J. Wong <djwong@us.ibm.com> wrote:
>  > > Hi there,
>  > >
>  > > Some old i386 systems have flaky APIC hardware that doesn't always
>  > > work right.  Right now, enabling the APIC code in Kconfig means that
>  > > the APIC code will try to activate the APICs unless 'noapic nolapic'
>  > > are passed to force them off.  The attached patch provides a config
>  > > option to change that default to keep the APICs off unless specified
>  > > otherwise, disables get_smp_config if we are not initializing the
>  > > local APIC, and makes init_apic_mappings not init the IOAPICs if they
>  > > are disabled. Note that the current behavior is maintained if
>  > > CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
>  >
>  > Did this hit the floor?
>
> It's still being kicked around.  I saw one patch off-list earlier this
> week that has some small improvements over the variant originally posted,
> but still had 1-2 kinks.

Cool. Let's get ironing. I have no idea about the implementation, but the 
concept is double ++ good as far as I'm concerned.

> The number of systems that actually *need* APIC enabled are in the
> vast (though growing) minority, so it's unlikely that most newbies
> will hit this.  The problem is also the inverse of what you describe.
> Typically the distros have DMI lists of machines that *need* APIC
> to make it enabled by default so everything 'just works'.

Ok, even more reason for it to go in. Someone might want to let the folks at 
Ubuntu know too, they seem to have it enabled in their installer kernel. :D

cheers

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] leave APIC code inactive by default on i386

[Dave Jones]

On Wed, Mar 01, 2006 at 04:10:26PM +1100, Michael Ellerman wrote:
 > > The number of systems that actually *need* APIC enabled are in the
 > > vast (though growing) minority, so it's unlikely that most newbies
 > > will hit this.  The problem is also the inverse of what you describe.
 > > Typically the distros have DMI lists of machines that *need* APIC
 > > to make it enabled by default so everything 'just works'.
 > 
 > Ok, even more reason for it to go in. Someone might want to let the folks at 
 > Ubuntu know too, they seem to have it enabled in their installer kernel. :D

Last I looked they picked up the same patch we were carrying in Fedora.

		Dave

Re: [PATCH] leave APIC code inactive by default on i386

[Matthew Garrett]

Dave Jones <davej@redhat.com> wrote:
> On Wed, Mar 01, 2006 at 04:10:26PM +1100, Michael Ellerman wrote:
> > 
> > Ok, even more reason for it to go in. Someone might want to let the folks at 
> > Ubuntu know too, they seem to have it enabled in their installer kernel. :D
> 
> Last I looked they picked up the same patch we were carrying in Fedora.

No, we use the standard kernel behaviour (use APIC if the BIOS enabled 
it, otherwise don't). 

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: [PATCH] leave APIC code inactive by default on i386

[Zwane Mwaikambo]

On Tue, 28 Feb 2006, Dave Jones wrote:

> On Wed, Mar 01, 2006 at 02:57:05PM +1100, Michael Ellerman wrote:
>  > On 1/20/06, Darrick J. Wong <djwong@us.ibm.com> wrote:
>  > > Hi there,
>  > >
>  > > Some old i386 systems have flaky APIC hardware that doesn't always work
>  > > right.  Right now, enabling the APIC code in Kconfig means that the APIC
>  > > code will try to activate the APICs unless 'noapic nolapic' are passed
>  > > to force them off.  The attached patch provides a config option to
>  > > change that default to keep the APICs off unless specified otherwise,
>  > > disables get_smp_config if we are not initializing the local APIC, and
>  > > makes init_apic_mappings not init the IOAPICs if they are disabled.
>  > > Note that the current behavior is maintained if
>  > > CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
>  > Did this hit the floor?
> 
> It's still being kicked around.  I saw one patch off-list earlier this
> week that has some small improvements over the variant originally posted,
> but still had 1-2 kinks.
> 
>  > It strikes me as a pretty good solution. This
>  > is pretty nasty for newbies installing distro kernels, they get some
>  > of the way through an install and then their machine just locks - not
>  > good PR.
> 
> The number of systems that actually *need* APIC enabled are in the
> vast (though growing) minority, so it's unlikely that most newbies
> will hit this.  The problem is also the inverse of what you describe.
> Typically the distros have DMI lists of machines that *need* APIC
> to make it enabled by default so everything 'just works'.
> 
> The big problem the patch solves is allowing it to be possible
> to build a kernel with UP APIC code, but disabled by default
> (Because there a lot of older machines that die horribly if it
>  was enabled by default).

The current policy is off if it was disabled by the BIOS. Is the intention 
of this patch to have it off unconditionally unless explicitely enabled by 
kernel parameter?

Thanks,
	Zwane

Re: [PATCH] leave APIC code inactive by default on i386

[Dave Jones]

On Tue, Feb 28, 2006 at 10:36:09PM -0800, Zwane Mwaikambo wrote:

 > > The number of systems that actually *need* APIC enabled are in the
 > > vast (though growing) minority, so it's unlikely that most newbies
 > > will hit this.  The problem is also the inverse of what you describe.
 > > Typically the distros have DMI lists of machines that *need* APIC
 > > to make it enabled by default so everything 'just works'.
 > > 
 > > The big problem the patch solves is allowing it to be possible
 > > to build a kernel with UP APIC code, but disabled by default
 > > (Because there a lot of older machines that die horribly if it
 > >  was enabled by default).
 > 
 > The current policy is off if it was disabled by the BIOS. Is the intention 
 > of this patch to have it off unconditionally unless explicitely enabled by 
 > kernel parameter?

Yes, (or forced on by dmi string)

		Dave

Re: [PATCH] leave APIC code inactive by default on i386

[Darrick J. Wong]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

On Tue, 2006-02-28 at 23:33 -0500, Dave Jones wrote:

> It's still being kicked around.  I saw one patch off-list earlier this
> week that has some small improvements over the variant originally posted,
> but still had 1-2 kinks.

Hm... what kinks are you referring to?  Anything you want me to look at?

--D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH] leave APIC code inactive by default on i386

[Dave Jones]

On Wed, Mar 01, 2006 at 01:29:06PM -0800, Darrick J. Wong wrote:
 > On Tue, 2006-02-28 at 23:33 -0500, Dave Jones wrote:
 > 
 > > It's still being kicked around.  I saw one patch off-list earlier this
 > > week that has some small improvements over the variant originally posted,
 > > but still had 1-2 kinks.
 > 
 > Hm... what kinks are you referring to?  Anything you want me to look at?

I think Konrad was on top of it, mostly just confusion over variants
of the same diff leading to things previously fixed being dropped again.

In light of Matthew's comments in this thread though, I'm also wondering
if we can now get by without this diff, and just enable it by default now
that the kernel respects that the BIOS and leaves it alone if it's been
disabled.

		Dave

Re: [PATCH] leave APIC code inactive by default on i386

[Darrick J. Wong]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Wed, 2006-03-01 at 17:14 -0500, Dave Jones wrote:

> In light of Matthew's comments in this thread though, I'm also wondering
> if we can now get by without this diff, and just enable it by default now
> that the kernel respects that the BIOS and leaves it alone if it's been
> disabled.

Actually, it seems that there are Lenovo ThinkCenter P4 machines with
buggy BIOSes that tell us that we can enable the APIC ... but doing so
eventually causes the system to hang.  Granted, the Google-recommended
fixes are "noapic" or "Update the BIOS", but perhaps it would be best to
leave it off _except_ for the few cases where we know that we need it.

(Then again, the correct solution in this case is to fix the BIOS...)

--D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH] leave APIC code inactive by default on i386

[Dave Jones]

On Wed, Mar 01, 2006 at 02:47:38PM -0800, Darrick J. Wong wrote:
 > On Wed, 2006-03-01 at 17:14 -0500, Dave Jones wrote:
 > 
 > > In light of Matthew's comments in this thread though, I'm also wondering
 > > if we can now get by without this diff, and just enable it by default now
 > > that the kernel respects that the BIOS and leaves it alone if it's been
 > > disabled.
 > 
 > Actually, it seems that there are Lenovo ThinkCenter P4 machines with
 > buggy BIOSes that tell us that we can enable the APIC ... but doing so
 > eventually causes the system to hang.  Granted, the Google-recommended
 > fixes are "noapic" or "Update the BIOS", but perhaps it would be best to
 > leave it off _except_ for the few cases where we know that we need it.
 > 
 > (Then again, the correct solution in this case is to fix the BIOS...)

Indeed. And also blacklist the bad ones with DMI entries.

		Dave

Re: [PATCH] leave APIC code inactive by default on i386

[Darrick J. Wong]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Wed, 2006-03-01 at 17:51 -0500, Dave Jones wrote:
> On Wed, Mar 01, 2006 at 02:47:38PM -0800, Darrick J. Wong wrote:
>  > On Wed, 2006-03-01 at 17:14 -0500, Dave Jones wrote:
>  > 
>  > > In light of Matthew's comments in this thread though, I'm also wondering
>  > > if we can now get by without this diff, and just enable it by default now
>  > > that the kernel respects that the BIOS and leaves it alone if it's been
>  > > disabled.
>  > 
>  > Actually, it seems that there are Lenovo ThinkCenter P4 machines with
>  > buggy BIOSes that tell us that we can enable the APIC ... but doing so
>  > eventually causes the system to hang.  Granted, the Google-recommended
>  > fixes are "noapic" or "Update the BIOS", but perhaps it would be best to
>  > leave it off _except_ for the few cases where we know that we need it.
>  > 
>  > (Then again, the correct solution in this case is to fix the BIOS...)
> 
> Indeed. And also blacklist the bad ones with DMI entries.

Yeah.  Since the kernel honors the BIOS's APIC settings, we might as
well enable the APIC code by default.

--D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH] leave APIC code inactive by default on i386

[Pavel Machek]

On Út 28-02-06 23:33:53, Dave Jones wrote:
> On Wed, Mar 01, 2006 at 02:57:05PM +1100, Michael Ellerman wrote:
>  > On 1/20/06, Darrick J. Wong <djwong@us.ibm.com> wrote:
>  > > Hi there,
>  > >
>  > > Some old i386 systems have flaky APIC hardware that doesn't always work
>  > > right.  Right now, enabling the APIC code in Kconfig means that the APIC
>  > > code will try to activate the APICs unless 'noapic nolapic' are passed
>  > > to force them off.  The attached patch provides a config option to
>  > > change that default to keep the APICs off unless specified otherwise,
>  > > disables get_smp_config if we are not initializing the local APIC, and
>  > > makes init_apic_mappings not init the IOAPICs if they are disabled.
>  > > Note that the current behavior is maintained if
>  > > CONFIG_X86_UP_APIC_DEFAULT_OFF=n.
>  > Did this hit the floor?
> 
> It's still being kicked around.  I saw one patch off-list earlier this
> week that has some small improvements over the variant originally posted,
> but still had 1-2 kinks.
> 
>  > It strikes me as a pretty good solution. This
>  > is pretty nasty for newbies installing distro kernels, they get some
>  > of the way through an install and then their machine just locks - not
>  > good PR.
> 
> The number of systems that actually *need* APIC enabled are in the
> vast (though growing) minority, so it's unlikely that most newbies
> will hit this.  The problem is also the inverse of what you describe.
> Typically the distros have DMI lists of machines that *need* APIC
> to make it enabled by default so everything 'just works'.

Well, blacklisting "new" machines is a problem -- their number
grows. Would not it be better to blacklist machines broken by APIC
("old" ones, presumably)?

> The big problem the patch solves is allowing it to be possible
> to build a kernel with UP APIC code, but disabled by default
> (Because there a lot of older machines that die horribly if it
>  was enabled by default).

Is adding "noapic nolapic" to default command line a big problem?
								Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...

Re: [PATCH] leave APIC code inactive by default on i386

[Dave Jones]

On Mon, Mar 06, 2006 at 01:50:18PM +0100, Pavel Machek wrote:

 > > The number of systems that actually *need* APIC enabled are in the
 > > vast (though growing) minority, so it's unlikely that most newbies
 > > will hit this.  The problem is also the inverse of what you describe.
 > > Typically the distros have DMI lists of machines that *need* APIC
 > > to make it enabled by default so everything 'just works'.
 > 
 > Well, blacklisting "new" machines is a problem -- their number
 > grows. Would not it be better to blacklist machines broken by APIC
 > ("old" ones, presumably)?

It would.  Though some new machines also falsely advertise it as
working aparently.  I heard a report of a thinkpad going boom last week.

 > Is adding "noapic nolapic" to default command line a big problem?

For end-users, yes.  People want things to 'just work', not have
to find arcane commands to type in to make things work.

		Dave


-- 
http://www.codemonkey.org.uk

Re: [PATCH] leave APIC code inactive by default on i386

[Pavel Machek]

>  > Is adding "noapic nolapic" to default command line a big problem?
> 
> For end-users, yes.  People want things to 'just work', not have
> to find arcane commands to type in to make things work.

If distro puts "noapic nolapic" on kernel command line, I'd say users
are unlikely to remove it.. And if they do remove it and it breaks,
they'll only blame themselves...

One more config-option is also not "cheap" (half of users will get it
wrong), and having config-option to change command-line-default seems
wrong to me.

[Well, you could add CONFIG_CMDLINE to i386, like arm has... that
solves more than just this problem...]
								Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...

Re: [PATCH] leave APIC code inactive by default on i386

[Dave Jones]

On Mon, Mar 06, 2006 at 06:41:22PM +0100, Pavel Machek wrote:

 > >  > Is adding "noapic nolapic" to default command line a big problem?
 > > For end-users, yes.  People want things to 'just work', not have
 > > to find arcane commands to type in to make things work.
 > If distro puts "noapic nolapic" on kernel command line, I'd say users
 > are unlikely to remove it.. And if they do remove it and it breaks,
 > they'll only blame themselves...

If distros put 'noapic nolapic' on the command line they've only
themselves to blame when systems that need local apic for
correct operation don't work.

 > One more config-option is also not "cheap" (half of users will get it
 > wrong), and having config-option to change command-line-default seems
 > wrong to me.
 >
 > [Well, you could add CONFIG_CMDLINE to i386, like arm has... that
 > solves more than just this problem...]

I'm not arguing for extra command line options. The inverse, I want
*no* command line options.

What's so hard to understand about expecting something to just work?

		Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH] leave APIC code inactive by default on i386

[Pavel Machek]

>  > One more config-option is also not "cheap" (half of users will get it
>  > wrong), and having config-option to change command-line-default seems
>  > wrong to me.
>  >
>  > [Well, you could add CONFIG_CMDLINE to i386, like arm has... that
>  > solves more than just this problem...]
> 
> I'm not arguing for extra command line options. The inverse, I want
> *no* command line options.
> 
> What's so hard to understand about expecting something to just work?

I don't argue with "just works". I just do not want to see
CONFIG_DO_NOAPIC_BY_DEFAULT someone suggested
here (heh, it is still in subject :-). Whitelist/blacklist is fine
with me.
								Pavel

-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...

Re: [PATCH] leave APIC code inactive by default on i386

[Dave Jones]

On Mon, Mar 06, 2006 at 06:58:11PM +0100, Pavel Machek wrote:

 > I just do not want to see CONFIG_DO_NOAPIC_BY_DEFAULT someone suggested
 > here (heh, it is still in subject :-). Whitelist/blacklist is fine
 > with me.

I (and Darrick) already agreed further up in this thread that it wasn't needed.
I think we're actually in agreement ;)

		Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH] leave APIC code inactive by default on i386

[Darrick J. Wong]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

On Mon, 2006-03-06 at 13:17 -0500, Dave Jones wrote:

> I (and Darrick) already agreed further up in this thread that it wasn't needed.
> I think we're actually in agreement ;)

Yep.  Maybe it's time I cough up a patch that does this. :)

--D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]