Hi Linus, please do a
bk pull bk://linux-acpi.bkbits.net/26-latest-release
I recommend that we include this patch in 2.6.9.
thanks,
-Len
ps. a plain patch is also available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/26-latest-release/acpi-20040816-26-latest-release.diff.gz
This will update the following files:
arch/i386/kernel/apic.c | 6 ++++++
1 files changed, 6 insertions(+)
through these ChangeSets:
<[email protected]> (04/10/10 1.2158)
[ACPI] If BIOS disabled the LAPIC, believe it by default.
"lapic" is available to force enabling the LAPIC
in the event you know more than your BIOS vendor.
http://bugzilla.kernel.org/show_bug.cgi?id=3238
On Sun, 10 Oct 2004, Len Brown wrote:
>
> Hi Linus, please do a
>
> bk pull bk://linux-acpi.bkbits.net/26-latest-release
Ok, this version of the patch suddenly looks like a real bug-fix in that
it now makes the command line options "lapic"/"nolapic" a lot more
logical.
Pulled.
Linus
On Sun, 10 Oct 2004, Linus Torvalds wrote:
> > Hi Linus, please do a
> >
> > bk pull bk://linux-acpi.bkbits.net/26-latest-release
>
> Ok, this version of the patch suddenly looks like a real bug-fix in that
> it now makes the command line options "lapic"/"nolapic" a lot more
> logical.
Hmm, any particular reason to keep the local APIC disabled by default?
Most BIOS vendors keep it disabled just because it's easier to get stuff
set up this way -- with the APIC enabled you need to do the same steps to
program the 8259As as with the APIC disabled, plus program the APIC
itself, which provides no gain to BIOS itself or to DOS, so why bother?
Maciej
On Sun, 2004-10-10 at 20:04, Maciej W. Rozycki wrote:
> On Sun, 10 Oct 2004, Linus Torvalds wrote:
>
> > > Hi Linus, please do a
> > >
> > > bk pull bk://linux-acpi.bkbits.net/26-latest-release
> >
> > Ok, this version of the patch suddenly looks like a real bug-fix in that
> > it now makes the command line options "lapic"/"nolapic" a lot more
> > logical.
>
> Hmm, any particular reason to keep the local APIC disabled by default?
> Most BIOS vendors keep it disabled just because it's easier to get stuff
> set up this way -- with the APIC enabled you need to do the same steps to
> program the 8259As as with the APIC disabled, plus program the APIC
> itself, which provides no gain to BIOS itself or to DOS, so why bother?
>
> Maciej
>
The problem is: trying enable some local apic's (for example on via
mother boards on my laptop), cause many problem, like hang on boot (with
ACPI), hang on Fn-F3 (video switch), power-off fails, etc. and no one
knows how resolved the problem.
So keep it disable if BIOS vendors say so, can be reasonable idea.
--
S?rgio M. B.
On Sun, 10 Oct 2004, Maciej W. Rozycki wrote:
>
> Hmm, any particular reason to keep the local APIC disabled by default?
Yes. It changes interrupt handling, so any SMM stuff tends to break on
BIOSes that don't know about APICs. Things like the magic keys etc. It
apparently also breaks some ACPI stuff (likely AML code that "knows" that
interrupts are done with the legacy controller).
Mostly a laptop issue, I suspect - simply because desktops don't do
anything strange these days.
So the default is the "safe" settings. And if you care, and your machine
works with the APIC, the command line thing is available.
Linus
On Sun, 10 Oct 2004, [ISO-8859-1] S?rgio Monteiro Basto wrote:
> The problem is: trying enable some local apic's (for example on via
> mother boards on my laptop), cause many problem, like hang on boot (with
> ACPI), hang on Fn-F3 (video switch), power-off fails, etc. and no one
> knows how resolved the problem.
Ah, laptops seem to be inherently insane... Your symptoms suggest your
firmware/BIOS is buggy, doing probably something under the OS, which
cannot be controlled and without taking proper care of the state of
hardware. That's the infamous SMM code.
How about only disabling the APIC if power-management is in use? And
announcing it so that a user sees the APIC has been kept deliberately
disabled, as opposed to be unable to be enabled? Like below -- for ACPI
only, as I assume APM gives no trouble or the change would have been
proposed much earlier. Untested.
> So keep it disable if BIOS vendors say so, can be reasonable idea.
BIOS vendors usually say so, because they have no clue, or in other
words, they do not really mean to say anything with this. They just don't
enable the APIC as they see no use for it, but the same can be true of
plenty of other hardware that has no use for the firmware.
I don't like the idea of "punishing" good hardware, because something
behaves ill out there.
Maciej
patch-mips-2.6.9-rc2-20040920-lapic-0
diff -up --recursive --new-file linux-mips-2.6.9-rc2-20040920.macro/arch/i386/kernel/acpi/boot.c linux-mips-2.6.9-rc2-20040920/arch/i386/kernel/acpi/boot.c
--- linux-mips-2.6.9-rc2-20040920.macro/arch/i386/kernel/acpi/boot.c 2004-08-25 03:57:43.000000000 +0000
+++ linux-mips-2.6.9-rc2-20040920/arch/i386/kernel/acpi/boot.c 2004-10-11 01:42:34.000000000 +0000
@@ -835,6 +835,19 @@ acpi_boot_init (void)
}
/*
+ * Don't override BIOS and enable the local APIC
+ * unless "lapic" specified.
+ */
+ if (!acpi_disabled && 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");
+ enable_local_apic = -1;
+ }
+
+ /*
* set sci_int and PM timer address
*/
acpi_table_parse(ACPI_FADT, acpi_parse_fadt);
diff -up --recursive --new-file linux-mips-2.6.9-rc2-20040920.macro/arch/i386/kernel/apic.c linux-mips-2.6.9-rc2-20040920/arch/i386/kernel/apic.c
--- linux-mips-2.6.9-rc2-20040920.macro/arch/i386/kernel/apic.c 2004-09-20 03:57:43.000000000 +0000
+++ linux-mips-2.6.9-rc2-20040920/arch/i386/kernel/apic.c 2004-10-11 01:37:13.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;
On Mon, 11 Oct 2004, Maciej W. Rozycki wrote:
>
> How about only disabling the APIC if power-management is in use?
No. You cannot test for SMM. Full stop. That's the whole _point_ of SMM.
It's hidden away.
Why do you care? If you have a machine with this problem, just use the
"lapic" command line. We do NOT default to unsafe values.
> I don't like the idea of "punishing" good hardware, because something
> behaves ill out there.
We don't punish good hardware.
We punish _bad_ hardware. The kind of hardware that has a BIOS that has
disabled the local APIC.
Try to get your BIOS updated if you want to consider your hardware "good".
And if the hw vendor doesn't have a fixed BIOS, then don't call it good,
and use "lapic".
Linus
On Sun, Oct 10, 2004 at 05:47:05PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 10 Oct 2004, Maciej W. Rozycki wrote:
> >
> > Hmm, any particular reason to keep the local APIC disabled by default?
>
> Yes. It changes interrupt handling, so any SMM stuff tends to break on
> BIOSes that don't know about APICs. Things like the magic keys etc. It
> apparently also breaks some ACPI stuff (likely AML code that "knows" that
> interrupts are done with the legacy controller).
>
> Mostly a laptop issue, I suspect - simply because desktops don't do
> anything strange these days.
It's more than a laptop issue. Especially older desktops still don't
work with APIC by default, and even a lot of modern ones have problems.
It works around ACPI bugs. Some common issues I ran into on x86-64:
nvidia nforce2/3 is still often broken because of the bogus timer override
so many BIOS have)
Some VIA K8 boards get mysterious IDE DMA errors after some time when the APIC
is on.
[Patch for the Nvidia thing is pending - just always ignore it - but not
submitted yet for i386 yet. x86-64 has it fixed in -mm*]
-Andi