Hi all,
The ACPI patches against 2.4 and 2.5 have been updated, and are now
available on http://sf.net/projects/acpi . Thanks to the acceptance of
the ACPI patch in 2.4, they are now both very small.
Regards -- Andy
----------------------------------------
14 July 2003. Summary of changes for version 20030619:
1) ACPI CA Core Subsystem:
Parse SSDTs in order discovered, as opposed to reverse order
(Hrvoje Habjanic)
Fixes from FreeBSD and NetBSD. (Frank van der Linden, Thomas
Klausner, Nate Lawson)
2) Linux:
Dynamically allocate SDT list (suggested by Andi Kleen)
proc function return value cleanups (Andi Kleen)
Correctly handle NMI watchdog during long stalls (Andrew Morton)
Make it so acpismp=force works (reported by Andrew Morton)
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
[email protected]
On Tue, 15 Jul 2003, Grover, Andrew wrote:
>
> Make it so acpismp=force works (reported by Andrew Morton)
But we don't want "acpismp=force" to work, it now serves no purpose
but to confuse. May I push again to Marcelo my patch you acked
before, which removes it completely? I had been waiting to say it's
in 2.6, but Andrew didn't push it from 2.5-mm into 2.6 - any reason?
Whereas we would still like "noht" to work, but it's now beyond me.
Hugh
> From: Hugh Dickins [mailto:[email protected]]
> > Make it so acpismp=force works (reported by Andrew Morton)
>
> But we don't want "acpismp=force" to work, it now serves no purpose
> but to confuse. May I push again to Marcelo my patch you acked
> before, which removes it completely? I had been waiting to say it's
> in 2.6, but Andrew didn't push it from 2.5-mm into 2.6 - any reason?
>
> Whereas we would still like "noht" to work, but it's now beyond me.
That patch was sitting in my bk tree but yeah it's kinda stale. Len
Brown was going to completely redo all this stuff, so Hugh if you have a
need for your fix in the interim then great feel free to push, but there
is a more comprehensive fix also in the works.
Regards -- Andy
On Tue, 15 Jul 2003, Grover, Andrew wrote:
> > From: Hugh Dickins [mailto:[email protected]]
> > > Make it so acpismp=force works (reported by Andrew Morton)
> >
> > But we don't want "acpismp=force" to work, it now serves no purpose
> > but to confuse. May I push again to Marcelo my patch you acked
> > before, which removes it completely? I had been waiting to say it's
> > in 2.6, but Andrew didn't push it from 2.5-mm into 2.6 - any reason?
> >
> > Whereas we would still like "noht" to work, but it's now beyond me.
>
> That patch was sitting in my bk tree but yeah it's kinda stale. Len
> Brown was going to completely redo all this stuff, so Hugh if you have a
> need for your fix in the interim then great feel free to push, but there
> is a more comprehensive fix also in the works.
I've no desperate need to push it, can easily apply the patch to my own
tree. It's just that Marcelo is motoring so speedily towards 2.4.22,
be a shame if that goes out with CONFIG_ACPI_HT_ONLY needing pointless
"acpismp=force" too. What's the schedule for Len's rework to Marcelo?
Hugh
On Tue, 2003-07-15 at 12:53, Grover, Andrew wrote:
> Hi all,
>
> The ACPI patches against 2.4 and 2.5 have been updated, and are now
> available on http://sf.net/projects/acpi . Thanks to the acceptance of
> the ACPI patch in 2.4, they are now both very small.
This fixes the lockup on boot on my Compaq W8000 introduced by the last
update.
http://acm.cs.nyu.edu/~tugrul/acpi/dmesg-2.6.0-test1-20030714
Yeay! :)
Tugrul Galatali
> What's the schedule for Len's rework to Marcelo?
I'm testing today and expect to push via Andy
(http://linux-acpi.bkbits.net/to-andy-2.4) when when I'm satisifed I
haven't toasted anything -- probably Wednesday.
Cheers,
-Len
Ps. Below is the current plan for ACPI build and boot knobs. Except for the
config syntax -- 2.4 and 2.5 should end up the same. Let me know if we
missed anything.
Audit of ACPI build and boot options
Scrubbed w/ Andy 7/10 -- see TODO for Lenb's plan
Build Options
-------------
Indentation shows dependency (from acpi/Kconfig, Makefile)
CONFIG_ACPI_HT_ONLY
depends on X86 && ACPI && X86_LOCAL_APIC
:= acpitable.o
TODO: simplify acpitable.c to only to LAPIC enumeration for HT
It probably shouldn't parse the non-LAPIC MADT entries
TODO: make this independent of the ACPI option:
ACPI && ACPI_HT_ONLY
Expect OSD's to build this way
acpitable.c runs only if boot with acpi=cpu
This matches SL8.2 distribution
!ACPI && ACPI_HT_ONLY
Minimal kernel to enable HT -- no ACPI
acpi=cpu is the default behaviour here
if somebody wants to disable ht, they can use "noht"
This matches RHL's 2.4 distribution
ACPI && !ACPI_HT_ONLY
Full ACPI w/o the acpi=cpu option
Maybe OSD's will get here some day
!ACPI && !ACPI_HT_ONLY
no HT, no ACPI
TODO: delete the !CONFIG_ACPI_HT_ONLY from the module dependencies
below.
They depend on ACPI, and don't care about
CONFIG_ACPI_HT_ONLY
CONFIG_ACPI
depends on !X86_VISWS (SGI visual workstation)
TODO: change this to "depends on IA64 && !IA64_HP_SIM || X86 && ACPI
&& !ACPI_HT_ONLY"
per CONFIG_ACPI_BOOT below
+= drivers/acpi/
CONFIG_ACPI_BOOT
depends on IA64 && (!IA64_HP_SIM || IA64_SGI_SN) || X86 &&
ACPI && !ACPI_HT_ONLY
TODO: This expression looks wrong IA64_SGI_SN should not be
necessary
TODO: add parens, b/c it looks like '||' is higher
presidence than '&&'
It doesn't make sense to have CONFIG_ACPI w/o
CONFIG_ACPI_BOOT
TODO: delete this option and fold CONFIG_ACPI_BOOT into
CONFIG_ACPI
:= boot.o
+= tables.o blacklist.o
CONFIG_X86_LOCAL_APIC
acpi_lapic
CONFIG_X86_IO_APIC
acpi_ioapic
CONFIG_ACPI_SLEEP
depends on X86 && ACPI && !ACPI_HT_ONLY && SOFTWARE_SUSPEND
+= main.o
+= sleep.o wakeup.o
CONFIG_ACPI_SLEEP_PROC_FS
depends on ACPI_SLEEP && PROC_FS
+= proc.o
CONFIG_ACPI_AC
depends on X86 && ACPI && !ACPI_HT_ONLY
+= ac.o
CONFIG_ACPI_BATTERY
depends on X86 && ACPI && !ACPI_HT_ONLY
+= battery.o
CONFIG_ACPI_BUTTON
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
+= button.o
CONFIG_ACPI_FAN
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
+= fan.o
CONFIG_ACPI_PROCESSOR
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
+= processor.o
CONFIG_ACPI_THERMAL
depends on ACPI_PROCESSOR
+= thermal.o
CONFIG_ACPI_NUMA
if NUMA && (IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY && !X86_64)
+= numa.o
CONFIG_ACPI_ASUS
depends on X86 && ACPI && !ACPI_HT_ONLY
+= asus_acpi.o
CONFIG_ACPI_TOSHIBA
depends on X86 && ACPI && !ACPI_HT_ONLY
+= toshiba_acpi.o
CONFIG_ACPI_DEBUG
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
enables -DACPI_DEBUG_OUTPUT
+= debug.o
CONFIG_ACPI_BUS
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
+= sleep/
:= poweroff.o
+= bus.o
+= scan.o
CONFIG_ACPI_INTERPRETER
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
osl.o utils.o \
dispatcher/ events/ executer/ hardware/ \
namespace/ parser/ resources/ tables/ \
utilities/
It doesn't make sense to have ACPI w/o the interpreter
TODO: fold into CONFIG_ACPI
CONFIG_ACPI_EC
depends on X86 && ACPI && !ACPI_HT_ONLY
+= ec.o
TODO: possibly fold into CONFIG_ACPI
? But what about IA64?
CONFIG_ACPI_POWER
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
+= power.o
CONFIG_ACPI_PCI
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
+= pci_root.o pci_link.o pci_irq.o pci_bind.o
TODO: depend on CONFIG_PCI (like 2.4 does)
CONFIG_ACPI_SYSTEM
depends on IA64 && !IA64_HP_SIM || X86 && ACPI &&
!ACPI_HT_ONLY
+= system.o event.o
CONFIG_ACPI_EFI
depends on IA64 && (!IA64_HP_SIM || IA64_SGI_SN)
used within osl.c
TODO: depend on CONFIG_ACPI
CONFIG_X86_LOCAL_APIC
ACPI_HT_ONLY depends on this
CONFIG_X86_IO_APIC
+= io_apic.o
Boot options:
------------
acpismp=force
TODO: Delete.
Used in 2.4 to force acpitable.c to configure HT.
But it because a no-op when the code was changed
to call acpitable.c whenever the cpu flags said HT was supported.
noht
Keep
TODO: fix
Disable HT for benefit of systems which perform better with HT
disabled, but
have a BIOS incapable of disabling HT.
currently broken in 2.5
acpi=off
Keep.
Don't config with ACPI
Don't load driver/interpreter, enter ACPI mode, or handle events
acpi=cpu
TODO: port SuSE's "acpi=oldboot" with name change to "acpi=cpu"
Minimal ACPI table support to allow cpu enumeration for benefit of
HT.
pci=noacpi
Keep.
On Tue, 15 Jul 2003 11:07:29 -0700, "Brown, Len" wrote:
>Ps. Below is the current plan for ACPI build and boot knobs. Except for the
>config syntax -- 2.4 and 2.5 should end up the same. Let me know if we
>missed anything.
>
>Audit of ACPI build and boot options
>Scrubbed w/ Andy 7/10 -- see TODO for Lenb's plan
>
>
>Build Options
>-------------
>Indentation shows dependency (from acpi/Kconfig, Makefile)
>
>CONFIG_ACPI_HT_ONLY
> depends on X86 && ACPI && X86_LOCAL_APIC
> := acpitable.o
>
> TODO: simplify acpitable.c to only to LAPIC enumeration for HT
> It probably shouldn't parse the non-LAPIC MADT entries
I would like to see HT_ONLY generalized to parsing the MADT for
I/O-APICs. The problem I have is that some mainboards, like my
i850 ASUS P4T-E, have I/O-APICs but no MP tables. The only way for
the Linux kernel to discover the I/O-APICs on these mainboard is
through MADT parsing.
However, this currently requires me to enable all of ACPI, which
I don't need or want for many reasons, including code bloat and
behavioural side-effects.
Replacing "HT_ONLY" with "MADT_PARSING_ONLY" would be ideal, IMO.
/Mikael
On Tue, 15 Jul 2003, Brown, Len wrote:
> > What's the schedule for Len's rework to Marcelo?
>
> I'm testing today and expect to push via Andy
> (http://linux-acpi.bkbits.net/to-andy-2.4) when when I'm satisifed I
> haven't toasted anything -- probably Wednesday.
Oh, thanks, that sounds very good, much the best if I don't interfere.
Three comments below.
> !ACPI && ACPI_HT_ONLY
> Minimal kernel to enable HT -- no ACPI
> acpi=cpu is the default behaviour here
> if somebody wants to disable ht, they can use "noht"
> This matches RHL's 2.4 distribution
>
> ACPI && !ACPI_HT_ONLY
> Full ACPI w/o the acpi=cpu option
> Maybe OSD's will get here some day
Shouldn't this combination also support "noht", or is that too much to ask?
> acpismp=force
> TODO: Delete.
Hurrah!
> noht
> Keep
> TODO: fix
> Disable HT for benefit of systems which perform better with HT
> disabled, but
> have a BIOS incapable of disabling HT.
> currently broken in 2.5
And it's currently broken in 2.4 also.
Thanks,
Hugh
> From: Mikael Pettersson [mailto:[email protected]]
> I would like to see HT_ONLY generalized to parsing the MADT for
> I/O-APICs. The problem I have is that some mainboards, like my
> i850 ASUS P4T-E, have I/O-APICs but no MP tables. The only way for
> the Linux kernel to discover the I/O-APICs on these mainboard is
> through MADT parsing.
>
> However, this currently requires me to enable all of ACPI, which
> I don't need or want for many reasons, including code bloat and
> behavioural side-effects.
>
> Replacing "HT_ONLY" with "MADT_PARSING_ONLY" would be ideal, IMO.
This won't help you. If you have *no* MPS tables, then you need ACPI
(and specifically the ability to execute the _PRT control methods) for
interrupt routing information, in addition to ioapic and local apic
(CPU) enumeration. If this wasn't the case, I'm sure someone would have
implemented ioapic MADT enumeration code long ago.
Also, nothing is going to fundamentally change the size of the ACPI code
(but we do keep chipping away at it, as evidenced by the dynamic SDT
patch, -Os, etc.) but I'd like to hear more about the behavioral
side-effects you'd mentioned, with an eye towards fixing them.
Regards -- Andy
> From: Hugh Dickins [mailto:[email protected]]
> > ACPI && !ACPI_HT_ONLY
> > Full ACPI w/o the acpi=cpu option
>
> Shouldn't this combination also support "noht", or is that
> too much to ask?
Can do. It will be called CONFIG_ACPI_HT, and will be required for ACPI to
enable HT -- with or without the full CONFIG_ACPI.
Cheers,
-Len
On Tue, 15 Jul 2003 12:11:17 -0700, "Grover, Andrew" wrote:
>> From: Mikael Pettersson [mailto:[email protected]]
>> I would like to see HT_ONLY generalized to parsing the MADT for
>> I/O-APICs. The problem I have is that some mainboards, like my
>> i850 ASUS P4T-E, have I/O-APICs but no MP tables. The only way for
>> the Linux kernel to discover the I/O-APICs on these mainboard is
>> through MADT parsing.
>>
>> However, this currently requires me to enable all of ACPI, which
>> I don't need or want for many reasons, including code bloat and
>> behavioural side-effects.
>>
>> Replacing "HT_ONLY" with "MADT_PARSING_ONLY" would be ideal, IMO.
>
>This won't help you. If you have *no* MPS tables, then you need ACPI
>(and specifically the ability to execute the _PRT control methods) for
>interrupt routing information, in addition to ioapic and local apic
>(CPU) enumeration. If this wasn't the case, I'm sure someone would have
>implemented ioapic MADT enumeration code long ago.
:-(
>Also, nothing is going to fundamentally change the size of the ACPI code
>(but we do keep chipping away at it, as evidenced by the dynamic SDT
>patch, -Os, etc.) but I'd like to hear more about the behavioral
>side-effects you'd mentioned, with an eye towards fixing them.
The main side-effect _was_ seeing the interpreter being run.
I didn't know it was needed for figuring out IRQ routing.
Concerning code size, the 70K number in ACPI's Kconfig help is
out of date. A minimal ACPI (all user-selectable suboptions
disabled) adds 145K to my 2.6.0-test1 kernel.
/Mikael
> From: Mikael Pettersson [mailto:[email protected]]
> Concerning code size, the 70K number in ACPI's Kconfig help is
> out of date. A minimal ACPI (all user-selectable suboptions
> disabled) adds 145K to my 2.6.0-test1 kernel.
Are you talking to the compressed or uncompressed kernel? Maybe we got
it backwards, but the 70K number was the bzImage size difference.
(Actually I just tried it again. We're 80K now. I blame gcc. ;-))
(And of course, since the kernel (incl. ACPI) dynamically allocates
memory, even the uncompressed kernel image doesn't account for the
kernel's true memory footprint...)
Regards -- Andy
On Wed, 16 Jul 2003 13:36:10 -0700, "Grover, Andrew" wrote:
> > From: Mikael Pettersson [mailto:[email protected]]
>
> > Concerning code size, the 70K number in ACPI's Kconfig help is
> > out of date. A minimal ACPI (all user-selectable suboptions
> > disabled) adds 145K to my 2.6.0-test1 kernel.
>
> Are you talking to the compressed or uncompressed kernel? Maybe we got
> it backwards, but the 70K number was the bzImage size difference.
> (Actually I just tried it again. We're 80K now. I blame gcc. ;-))
Uncompressed: size vmlinux. gcc-3.2.2.