Hi,
after upgrading to 2.6.9-rc4 I'm getting the following message in dmesg:
No local APIC present or hardware disabled
2.6.9-rc3 and older kernels did not show this message. They showed:
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Any hints ?
Machine is an Acer Travelmate 291lci laptop.
Config is attached. Do you need any other information?
Regards, Sebastian
[email protected] writes:
> Hi,
>
> after upgrading to 2.6.9-rc4 I'm getting the following message in dmesg:
>
> No local APIC present or hardware disabled
>
> 2.6.9-rc3 and older kernels did not show this message. They showed:
> Local APIC disabled by BIOS -- reenabling.
> Found and enabled local APIC!
>
> Any hints ?
Boot with "lapic" to force-enable the local APIC.
Automatically overriding the BIOS was considered a bug in
some quarters (mainly ACPI), so the code was changed to
require a kernel boot option to enable the override.
BIOSen suck.
[email protected] schrieb:
> Hi,
>
> after upgrading to 2.6.9-rc4 I'm getting the following message in dmesg:
>
> No local APIC present or hardware disabled
>
> 2.6.9-rc3 and older kernels did not show this message. They showed:
> Local APIC disabled by BIOS -- reenabling.
> Found and enabled local APIC!
>
> Any hints ?
Use kernel parameter: lapic
It was decided the kernel should not automatically use local apic if
bios hasn't activated it.
Prakash
On Tue, 12 Oct 2004, [email protected] wrote:
> after upgrading to 2.6.9-rc4 I'm getting the following message in dmesg:
>
> No local APIC present or hardware disabled
>
> 2.6.9-rc3 and older kernels did not show this message. They showed:
> Local APIC disabled by BIOS -- reenabling.
> Found and enabled local APIC!
As you've already been told, the local APIC is not being enabled by
default anymore. I think this change may be unfortunate for users, so
I've proposed the change to be applied for systems using ACPI and then
verbosely, so that the reason for the APIC being kept disabled is clear.
Unfortunately I have no system available for testing that uses ACPI, so
I'm asking whether you could participate in testing of the following
patch. With the patch applied, you should either get a warning or the
local APIC running (e.g. if you disable ACPI by specifying "noacpi").
Does the patch work for you? For anyone else?
Maciej
patch-2.6.9-rc4-lapic-5
diff -up --recursive --new-file linux-2.6.9-rc4.macro/arch/i386/kernel/acpi/boot.c linux-2.6.9-rc4/arch/i386/kernel/acpi/boot.c
--- linux-2.6.9-rc4.macro/arch/i386/kernel/acpi/boot.c 2004-10-12 23:57:01.000000000 +0000
+++ linux-2.6.9-rc4/arch/i386/kernel/acpi/boot.c 2004-10-13 23:27:03.000000000 +0000
@@ -30,6 +30,7 @@
#include <linux/irq.h>
#include <linux/module.h>
+#include <asm/cpufeature.h>
#include <asm/pgtable.h>
#include <asm/io_apic.h>
#include <asm/apic.h>
@@ -842,6 +843,18 @@ acpi_boot_init (void)
}
/*
+ * Don't override BIOS and enable the local APIC
+ * unless "lapic" specified.
+ */
+ if (!acpi_disabled && !cpu_has_apic && enable_local_apic == 0) {
+ printk(KERN_NOTICE PREFIX "Local APIC won't be reenabled, "
+ "because of frequent BIOS bugs\n");
+ printk(KERN_NOTICE PREFIX
+ "You can enable it with \"lapic\"\n");
+ disable_lapic();
+ }
+
+ /*
* set sci_int and PM timer address
*/
acpi_table_parse(ACPI_FADT, acpi_parse_fadt);
diff -up --recursive --new-file linux-2.6.9-rc4.macro/arch/i386/kernel/apic.c linux-2.6.9-rc4/arch/i386/kernel/apic.c
--- linux-2.6.9-rc4.macro/arch/i386/kernel/apic.c 2004-10-12 23:57:01.000000000 +0000
+++ linux-2.6.9-rc4/arch/i386/kernel/apic.c 2004-10-13 00:14:58.000000000 +0000
@@ -667,7 +667,7 @@ static int __init detect_init_APIC (void
u32 h, l, features;
extern void get_cpu_vendor(struct cpuinfo_x86*);
- /* Disabled by DMI scan or kernel option? */
+ /* Disabled by DMI scan, ACPI or kernel option? */
if (enable_local_apic < 0)
return -1;
@@ -692,12 +692,6 @@ static int __init detect_init_APIC (void
if (!cpu_has_apic) {
/*
- * Over-ride BIOS and try to enable LAPIC
- * only if "lapic" specified
- */
- if (enable_local_apic != 1)
- goto no_apic;
- /*
* Some BIOSes disable the local APIC in the
* APIC_BASE MSR. This can only be done in
* software for Intel P6 and AMD K7 (Model > 1).
diff -up --recursive --new-file linux-2.6.9-rc4.macro/include/asm-i386/apic.h linux-2.6.9-rc4/include/asm-i386/apic.h
--- linux-2.6.9-rc4.macro/include/asm-i386/apic.h 2004-10-12 23:58:10.000000000 +0000
+++ linux-2.6.9-rc4/include/asm-i386/apic.h 2004-10-13 19:55:55.000000000 +0000
@@ -107,6 +107,12 @@ extern int APIC_init_uniprocessor (void)
extern void disable_APIC_timer(void);
extern void enable_APIC_timer(void);
+extern int enable_local_apic;
+static inline void disable_lapic(void)
+{
+ enable_local_apic = -1;
+}
+
extern int check_nmi_watchdog (void);
extern void enable_NMI_through_LVT0 (void * dummy);
@@ -116,6 +122,11 @@ extern unsigned int nmi_watchdog;
#define NMI_LOCAL_APIC 2
#define NMI_INVALID 3
-#endif /* CONFIG_X86_LOCAL_APIC */
+#else /* !CONFIG_X86_LOCAL_APIC */
+
+#define enable_local_apic -1
+static inline void disable_lapic(void) { /* nothing */ }
+
+#endif /* !CONFIG_X86_LOCAL_APIC */
#endif /* __ASM_APIC_H */
On Thu, 14 Oct 2004 00:59:13 +0100 (BST)
"Maciej W. Rozycki" <[email protected]> wrote:
> On Tue, 12 Oct 2004, [email protected] wrote:
>
> > after upgrading to 2.6.9-rc4 I'm getting the following message in
> > dmesg:
> >
> > No local APIC present or hardware disabled
> >
> > 2.6.9-rc3 and older kernels did not show this message. They showed:
> > Local APIC disabled by BIOS -- reenabling.
> > Found and enabled local APIC!
>
> As you've already been told, the local APIC is not being enabled by
> default anymore. I think this change may be unfortunate for users, so
> I've proposed the change to be applied for systems using ACPI and then
> verbosely, so that the reason for the APIC being kept disabled is
> clear. Unfortunately I have no system available for testing that uses
> ACPI, so I'm asking whether you could participate in testing of the
> following patch. With the patch applied, you should either get a
> warning or the local APIC running (e.g. if you disable ACPI by
> specifying "noacpi"). Does the patch work for you? For anyone else?
>
> Maciej
>
> patch-2.6.9-rc4-lapic-5
>
> <snip patch>
Hi,
i tested your patch, but it did not apply correctly to a clean 2.6.9-rc4
tree for me. (patch -Np1 -i ../patch-2.6.9-rc4-lapic-5)
I applyed it manually, and when rebooting, i get the following:
Local APIC won't be reenabled, ...
You can...
When booting with 'pci=noacpi':
Local APIC won't be reenabled, ...
You can...
When booting with 'acpi=off':
no output when running dmesg|grep -i apic
Regards, Sebastian
Maciej W. Rozycki writes:
> On Tue, 12 Oct 2004, [email protected] wrote:
>
> > after upgrading to 2.6.9-rc4 I'm getting the following message in dmesg:
> >
> > No local APIC present or hardware disabled
> >
> > 2.6.9-rc3 and older kernels did not show this message. They showed:
> > Local APIC disabled by BIOS -- reenabling.
> > Found and enabled local APIC!
>
> As you've already been told, the local APIC is not being enabled by
> default anymore. I think this change may be unfortunate for users, so
> I've proposed the change to be applied for systems using ACPI and then
> verbosely, so that the reason for the APIC being kept disabled is clear.
There are systems, such as the P3-based Dell Inspirons and Latitutes
that caused the dmi blacklist to be implemented, that fail whether
they're using APM or ACPI. So in the interest of consistency, we should
either always automatically override the BIOS, requiring "nolapic" on
broken systems, or never automatically override the BIOS, requiring
"lapic" on systems that work but have stupid BIOSen.
None of this is ACPI-specific, so I don't like the idea of tying
auto-enable/disable to ACPI.
/Mikael
On Thu, 14 Oct 2004, [email protected] wrote:
> i tested your patch, but it did not apply correctly to a clean 2.6.9-rc4
> tree for me. (patch -Np1 -i ../patch-2.6.9-rc4-lapic-5)
Strange.
> I applyed it manually, and when rebooting, i get the following:
> Local APIC won't be reenabled, ...
> You can...
>
> When booting with 'pci=noacpi':
> Local APIC won't be reenabled, ...
> You can...
>
> When booting with 'acpi=off':
> no output when running dmesg|grep -i apic
Thanks, these are expected results. Note that with 2.6.9 someone decided
to disable APIC-related messages by default, so you won't get any
information from the log unless you pass e.g. "apic=debug".
Maciej
On Thu, 14 Oct 2004, Mikael Pettersson wrote:
> There are systems, such as the P3-based Dell Inspirons and Latitutes
> that caused the dmi blacklist to be implemented, that fail whether
> they're using APM or ACPI. So in the interest of consistency, we should
> either always automatically override the BIOS, requiring "nolapic" on
> broken systems, or never automatically override the BIOS, requiring
> "lapic" on systems that work but have stupid BIOSen.
It's a pity another useful feature gets disfavored due to firmware bugs
in newer systems.
> None of this is ACPI-specific, so I don't like the idea of tying
> auto-enable/disable to ACPI.
I hope I won't hit the length limit of the command line this way, sigh...
Anyway, if this is going to stay in, I think code needs to be cleaned up
to get rid of dead bits and inaccurate comments. Here's my proposal.
Does it make sense? I hope so.
Maciej
patch-2.6.9-rc4-lapic-6
diff -up --recursive --new-file linux-2.6.9-rc4.macro/arch/i386/kernel/apic.c linux-2.6.9-rc4/arch/i386/kernel/apic.c
--- linux-2.6.9-rc4.macro/arch/i386/kernel/apic.c 2004-10-12 23:57:01.000000000 +0000
+++ linux-2.6.9-rc4/arch/i386/kernel/apic.c 2004-10-14 21:42:57.000000000 +0000
@@ -667,7 +667,7 @@ static int __init detect_init_APIC (void
u32 h, l, features;
extern void get_cpu_vendor(struct cpuinfo_x86*);
- /* Disabled by DMI scan or kernel option? */
+ /* Disabled by kernel option? */
if (enable_local_apic < 0)
return -1;
@@ -681,8 +681,7 @@ static int __init detect_init_APIC (void
break;
goto no_apic;
case X86_VENDOR_INTEL:
- if (boot_cpu_data.x86 == 6 ||
- (boot_cpu_data.x86 == 15 && (cpu_has_apic || enable_local_apic > 0)) ||
+ if (boot_cpu_data.x86 == 6 || boot_cpu_data.x86 == 15 ||
(boot_cpu_data.x86 == 5 && cpu_has_apic))
break;
goto no_apic;
@@ -692,15 +691,20 @@ static int __init detect_init_APIC (void
if (!cpu_has_apic) {
/*
- * Over-ride BIOS and try to enable LAPIC
- * only if "lapic" specified
+ * Over-ride BIOS and try to enable the local
+ * APIC only if "lapic" specified.
*/
- if (enable_local_apic != 1)
- goto no_apic;
+ if (enable_local_apic <= 0) {
+ printk("Not enabling local APIC "
+ "because of frequent BIOS bugs\n");
+ printk("You can enable it with \"lapic\"\n");
+ return -1;
+ }
/*
* Some BIOSes disable the local APIC in the
* APIC_BASE MSR. This can only be done in
- * software for Intel P6 and AMD K7 (Model > 1).
+ * software for Intel P6, Intel P4 and AMD K7
+ * (Model > 1).
*/
rdmsr(MSR_IA32_APICBASE, l, h);
if (!(l & MSR_IA32_APICBASE_ENABLE)) {
On Iau, 2004-10-14 at 23:27, Maciej W. Rozycki wrote:
> + printk("Not enabling local APIC "
> + "because of frequent BIOS bugs\n");
> + printk("You can enable it with \"lapic\"\n");
> + return -1;
> + }
Looks completely wrong to me. The BIOS disabled it or left it disabled
because they chose not to support it. We enabled it and then relied on
bios functionality.
Our bug
Maciej W. Rozycki writes:
> @@ -667,7 +667,7 @@ static int __init detect_init_APIC (void
> u32 h, l, features;
> extern void get_cpu_vendor(struct cpuinfo_x86*);
>
> - /* Disabled by DMI scan or kernel option? */
> + /* Disabled by kernel option? */
> if (enable_local_apic < 0)
> return -1;
>
DMI scan may still be relevant. Previously we used it to
override the default force-enable policy. Now we may still
need it to force-disable the lapic on systems that boot with
it enabled but malfunction if it's used. (I don't know of
any, but given BIOS history, they aren't impossible.)
So the comment doesn't need to change.
> @@ -681,8 +681,7 @@ static int __init detect_init_APIC (void
> break;
> goto no_apic;
> case X86_VENDOR_INTEL:
> - if (boot_cpu_data.x86 == 6 ||
> - (boot_cpu_data.x86 == 15 && (cpu_has_apic || enable_local_apic > 0)) ||
> + if (boot_cpu_data.x86 == 6 || boot_cpu_data.x86 == 15 ||
> (boot_cpu_data.x86 == 5 && cpu_has_apic))
> break;
> goto no_apic;
Looks Ok
> @@ -692,15 +691,20 @@ static int __init detect_init_APIC (void
>
> if (!cpu_has_apic) {
> /*
> - * Over-ride BIOS and try to enable LAPIC
> - * only if "lapic" specified
> + * Over-ride BIOS and try to enable the local
> + * APIC only if "lapic" specified.
> */
> - if (enable_local_apic != 1)
> - goto no_apic;
> + if (enable_local_apic <= 0) {
> + printk("Not enabling local APIC "
> + "because of frequent BIOS bugs\n");
> + printk("You can enable it with \"lapic\"\n");
> + return -1;
I agree with Alan that accusing the BIOS of being buggy is unwarranted.
The text should just state the obvious:
The local APIC was disabled by the BIOS.
You can enable it with "lapic".
> + }
> /*
> * Some BIOSes disable the local APIC in the
> * APIC_BASE MSR. This can only be done in
> - * software for Intel P6 and AMD K7 (Model > 1).
> + * software for Intel P6, Intel P4 and AMD K7
> + * (Model > 1).
To implicitly include P4 and K8, just change this to:
Intel P6 and later, and AMD K7 (Model > 1) and later
/Mikael
On Fri, 15 Oct 2004, Mikael Pettersson wrote:
> > @@ -667,7 +667,7 @@ static int __init detect_init_APIC (void
> > u32 h, l, features;
> > extern void get_cpu_vendor(struct cpuinfo_x86*);
> >
> > - /* Disabled by DMI scan or kernel option? */
> > + /* Disabled by kernel option? */
> > if (enable_local_apic < 0)
> > return -1;
> >
>
> DMI scan may still be relevant. Previously we used it to
> override the default force-enable policy. Now we may still
> need it to force-disable the lapic on systems that boot with
> it enabled but malfunction if it's used. (I don't know of
> any, but given BIOS history, they aren't impossible.)
We don't disable APIC right now, so this may only become true once it's
done (e.g. disable_local_APIC() is called from here).
> So the comment doesn't need to change.
I don't think keeping an inaccurate comment is good. Simply add it back
if it becomes relevant.
> > @@ -692,15 +691,20 @@ static int __init detect_init_APIC (void
> >
> > if (!cpu_has_apic) {
> > /*
> > - * Over-ride BIOS and try to enable LAPIC
> > - * only if "lapic" specified
> > + * Over-ride BIOS and try to enable the local
> > + * APIC only if "lapic" specified.
> > */
> > - if (enable_local_apic != 1)
> > - goto no_apic;
> > + if (enable_local_apic <= 0) {
> > + printk("Not enabling local APIC "
> > + "because of frequent BIOS bugs\n");
> > + printk("You can enable it with \"lapic\"\n");
> > + return -1;
>
> I agree with Alan that accusing the BIOS of being buggy is unwarranted.
I disagree. If the firmware performs any actions on hardware without
asking the OS for permission, it *must* be prepared for it to be in any
possible state and handle it correctly, including any transitional states
(as it does respect spinlocks). Otherwise it's buggy.
Alan, referring to your statement: it's like stating we must only use the
text mode of the display adapter, because that's the state it's left in by
the firmware and it may not expect any other state.
> The text should just state the obvious:
>
> The local APIC was disabled by the BIOS.
> You can enable it with "lapic".
I don't insist on any particular message though -- the following one
should hopefully suit you as more neutral (but you risk questions: "Why
doesn't Linux enable the APIC anymore?").
> > /*
> > * Some BIOSes disable the local APIC in the
> > * APIC_BASE MSR. This can only be done in
> > - * software for Intel P6 and AMD K7 (Model > 1).
> > + * software for Intel P6, Intel P4 and AMD K7
> > + * (Model > 1).
>
> To implicitly include P4 and K8, just change this to:
> Intel P6 and later, and AMD K7 (Model > 1) and later
Done.
Here's a new patch, updated for the 2.6.9 release.
Maciej
patch-2.6.9-lapic-7
diff -up --recursive --new-file linux-2.6.9.macro/arch/i386/kernel/apic.c linux-2.6.9/arch/i386/kernel/apic.c
--- linux-2.6.9.macro/arch/i386/kernel/apic.c 2004-10-12 23:57:01.000000000 +0000
+++ linux-2.6.9/arch/i386/kernel/apic.c 2004-10-24 00:30:29.000000000 +0000
@@ -667,7 +667,7 @@ static int __init detect_init_APIC (void
u32 h, l, features;
extern void get_cpu_vendor(struct cpuinfo_x86*);
- /* Disabled by DMI scan or kernel option? */
+ /* Disabled by kernel option? */
if (enable_local_apic < 0)
return -1;
@@ -681,8 +681,7 @@ static int __init detect_init_APIC (void
break;
goto no_apic;
case X86_VENDOR_INTEL:
- if (boot_cpu_data.x86 == 6 ||
- (boot_cpu_data.x86 == 15 && (cpu_has_apic || enable_local_apic > 0)) ||
+ if (boot_cpu_data.x86 == 6 || boot_cpu_data.x86 == 15 ||
(boot_cpu_data.x86 == 5 && cpu_has_apic))
break;
goto no_apic;
@@ -692,15 +691,20 @@ static int __init detect_init_APIC (void
if (!cpu_has_apic) {
/*
- * Over-ride BIOS and try to enable LAPIC
- * only if "lapic" specified
+ * Over-ride BIOS and try to enable the local
+ * APIC only if "lapic" specified.
*/
- if (enable_local_apic != 1)
- goto no_apic;
+ if (enable_local_apic <= 0) {
+ apic_printk(APIC_VERBOSE,
+ "Local APIC disabled by BIOS -- "
+ "you can enable it with \"lapic\"\n");
+ return -1;
+ }
/*
* Some BIOSes disable the local APIC in the
* APIC_BASE MSR. This can only be done in
- * software for Intel P6 and AMD K7 (Model > 1).
+ * software for Intel P6 or later and AMD K7
+ * (Model > 1) or later.
*/
rdmsr(MSR_IA32_APICBASE, l, h);
if (!(l & MSR_IA32_APICBASE_ENABLE)) {
On Sul, 2004-10-24 at 16:44, Maciej W. Rozycki wrote:
> > I agree with Alan that accusing the BIOS of being buggy is unwarranted.
>
> I disagree. If the firmware performs any actions on hardware without
> asking the OS for permission, it *must* be prepared for it to be in any
> possible state and handle it correctly, including any transitional states
> (as it does respect spinlocks). Otherwise it's buggy.
Show me a PC standards document that says this - there are none.
> Alan, referring to your statement: it's like stating we must only use the
> text mode of the display adapter, because that's the state it's left in by
> the firmware and it may not expect any other state.
If you switch video mode without using the BIOS then the BIOS video
calls are not guaranteed to work. Its the same thing.
> + if (enable_local_apic <= 0) {
> + apic_printk(APIC_VERBOSE,
> + "Local APIC disabled by BIOS -- "
> + "you can enable it with \"lapic\"\n");
> + return -1;
Looks good to me in this form.
Maciej W. Rozycki writes:
> > I agree with Alan that accusing the BIOS of being buggy is unwarranted.
>
> I disagree. If the firmware performs any actions on hardware without
> asking the OS for permission, it *must* be prepared for it to be in any
> possible state and handle it correctly, including any transitional states
> (as it does respect spinlocks). Otherwise it's buggy.
But in this case the BIOS explicitly disabled the local APIC. It may
have a legitimate reason for doing so (e.g. old #SMM code), so if the
Linux kernel overrides that disablement and things break, it really is
the kernel's fault not the BIOS'.
> patch-2.6.9-lapic-7
I'm Ok with this patch.
/Mikael