RE: ACPI patches updated (20030714)

RE: ACPI patches updated (20030714)

[Grover, Andrew]

> From: Mikael Pettersson [mailto:mikpe@csd.uu.se] 
> 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

RE: ACPI patches updated (20030714)

[Mikael Pettersson]

On Wed, 16 Jul 2003 13:36:10 -0700, "Grover, Andrew" wrote:
> > From: Mikael Pettersson [mailto:mikpe@csd.uu.se] 
> 
> > 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.

RE: ACPI patches updated (20030714)

[Grover, Andrew]

> From: Mikael Pettersson [mailto:mikpe@csd.uu.se] 

> 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

RE: ACPI patches updated (20030714)

[Mikael Pettersson]

On Tue, 15 Jul 2003 12:11:17 -0700, "Grover, Andrew" wrote:
>> From: Mikael Pettersson [mailto:mikpe@csd.uu.se] 
>> 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

RE: ACPI patches updated (20030714)

[Brown, Len]

> From: Hugh Dickins [mailto:hugh@veritas.com] 

> > 		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

RE: ACPI patches updated (20030714)

[Mikael Pettersson]

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

RE: ACPI patches updated (20030714)

[Brown, Len]

> 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.

RE: ACPI patches updated (20030714)

[Hugh Dickins]

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

RE: ACPI patches updated (20030714)

[Grover, Andrew]

> From: Hugh Dickins [mailto:hugh@veritas.com] 
> > 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

RE: ACPI patches updated (20030714)

[Hugh Dickins]

On Tue, 15 Jul 2003, Grover, Andrew wrote:
> > From: Hugh Dickins [mailto:hugh@veritas.com] 
> > > 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

ACPI patches updated (20030714)

[Grover, Andrew]

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
andrew.grover@intel.com

Re: ACPI patches updated (20030714)

[Hugh Dickins]

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

Re: ACPI patches updated (20030714)

[Tugrul Galatali]

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