broken ACPI NUMA config option

broken ACPI NUMA config option

[James C. Georgas]

If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
automatically, but ACPI is not selected automatically. This causes
ACPI_NUMA to not be built, and the kernel compile fails with unresolved
symbols.

Steps to reproduce:

	make clean
	make mrproper
	make noallconfig

	select SMP
	select NUMA
	select X86_64_ACPI_NUMA

	make
	<boom>

results:

	  LD      .tmp_vmlinux1
	drivers/built-in.o: In function `acpi_bus_generate_event':
	(.text+0x23365): undefined reference to `event_is_open'
	drivers/built-in.o: In function `acpi_bus_get_power':
	(.text+0x2361d): undefined reference to `acpi_power_get_inferred_state'
	drivers/built-in.o: In function `acpi_bus_set_power':
	(.text+0x23733): undefined reference to `acpi_power_transition'
	drivers/built-in.o: In function `acpi_bus_set_power':
	(.text+0x237a5): undefined reference to `acpi_power_transition'
	make: *** [.tmp_vmlinux1] Error 1

James
	/\V

Re: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote:
> Steps to reproduce:
> 
> 	make clean
> 	make mrproper
> 	make noallconfig

Excuse me; that should read allnoconfig, not noallconfig.

James
	/\V

Re: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote:
> If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> automatically, but ACPI is not selected automatically. This causes
> ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> symbols.
> 

Uh, it seems that I'm getting different results this time. Now,
X86_64_ACPI_NUMA does select ACPI, but PM (parent of ACPI) is not
automatically selected. Same result for the compile, though. Boom.

I seem to get different behaviour in general on subsequent runs of make
menuconfig.

For example, the last time I ran it, I was able to select K8_NUMA and
X86_64_ACPI_NUMA, independently of one another.

This time, though, the visibility of K8_NUMA is dependent on whether or
not X86_64_ACPI_NUMA is selected.

Should K8_NUMA and X86_64_ACPI_NUMA both be under NUMA, and independent
of one another?

James
	/\V

Re: broken ACPI NUMA config option

[Randy Dunlap]

On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:

> If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> automatically, but ACPI is not selected automatically. This causes
> ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> symbols.

exactly what kernel version??


> Steps to reproduce:
> 
> 	make clean
> 	make mrproper
> 	make noallconfig
> 
> 	select SMP
> 	select NUMA
> 	select X86_64_ACPI_NUMA
> 
> 	make
> 	<boom>
> 
> results:
> 
> 	  LD      .tmp_vmlinux1
> 	drivers/built-in.o: In function `acpi_bus_generate_event':
> 	(.text+0x23365): undefined reference to `event_is_open'
> 	drivers/built-in.o: In function `acpi_bus_get_power':
> 	(.text+0x2361d): undefined reference to `acpi_power_get_inferred_state'
> 	drivers/built-in.o: In function `acpi_bus_set_power':
> 	(.text+0x23733): undefined reference to `acpi_power_transition'
> 	drivers/built-in.o: In function `acpi_bus_set_power':
> 	(.text+0x237a5): undefined reference to `acpi_power_transition'
> 	make: *** [.tmp_vmlinux1] Error 1


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: broken ACPI NUMA config option

[Randy Dunlap]

On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote:

> On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
> 
> > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> > automatically, but ACPI is not selected automatically. This causes
> > ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> > symbols.
> 
> exactly what kernel version??
> 

2.6.23-rc5-git1 builds for me when I follow those steps...
except for some Section mismatch warnings.


> > Steps to reproduce:
> > 
> > 	make clean
> > 	make mrproper
> > 	make noallconfig
> > 
> > 	select SMP
> > 	select NUMA
> > 	select X86_64_ACPI_NUMA
> > 
> > 	make
> > 	<boom>
> > 
> > results:
> > 
> > 	  LD      .tmp_vmlinux1
> > 	drivers/built-in.o: In function `acpi_bus_generate_event':
> > 	(.text+0x23365): undefined reference to `event_is_open'
> > 	drivers/built-in.o: In function `acpi_bus_get_power':
> > 	(.text+0x2361d): undefined reference to `acpi_power_get_inferred_state'
> > 	drivers/built-in.o: In function `acpi_bus_set_power':
> > 	(.text+0x23733): undefined reference to `acpi_power_transition'
> > 	drivers/built-in.o: In function `acpi_bus_set_power':
> > 	(.text+0x237a5): undefined reference to `acpi_power_transition'
> > 	make: *** [.tmp_vmlinux1] Error 1
> 
> 
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:

> 2.6.23-rc5-git1 builds for me when I follow those steps...
> except for some Section mismatch warnings.
> 

OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour
of the "select" directive in Kconfig appears to have changed since
2.6.22.6. It now turns on ACPI, even when PM is not selected.

This still looks broken to me, because ACPI gets selected by ACPI_NUMA,
and ACPI depends on PM, but PM is not selected. It works out in the end,
as far as the build is concerned, but it still bugs me.

Does anyone object to the idea of a selected item automatically
selecting its own dependencies?

For example, you would only need to specify one "select" directive in
X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
on what it needed.

James
	/\V

Re: broken ACPI NUMA config option

[Yinghai Lu]

On 9/8/07, James C. Georgas <jgeorgas@georgas.ca> wrote:
> On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
>
> > 2.6.23-rc5-git1 builds for me when I follow those steps...
> > except for some Section mismatch warnings.
> >
>
> OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour
> of the "select" directive in Kconfig appears to have changed since
> 2.6.22.6. It now turns on ACPI, even when PM is not selected.
>
> This still looks broken to me, because ACPI gets selected by ACPI_NUMA,
> and ACPI depends on PM, but PM is not selected. It works out in the end,
> as far as the build is concerned, but it still bugs me.
>
> Does anyone object to the idea of a selected item automatically
> selecting its own dependencies?
>
> For example, you would only need to specify one "select" directive in
> X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
> would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
> on what it needed.

dont know my old patch still can be applied or not..
http://lkml.org/lkml/2007/4/4/17

Andi was talking about to use ACPI numa aka SRAT table, but not use dsdt ....

YH

Re: broken ACPI NUMA config option

[Randy Dunlap]

On Sat, 08 Sep 2007 23:48:56 -0400 James C. Georgas wrote:

> On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
> 
> > 2.6.23-rc5-git1 builds for me when I follow those steps...
> > except for some Section mismatch warnings.
> > 
> 
> OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour
> of the "select" directive in Kconfig appears to have changed since
> 2.6.22.6. It now turns on ACPI, even when PM is not selected.
> 
> This still looks broken to me, because ACPI gets selected by ACPI_NUMA,
> and ACPI depends on PM, but PM is not selected. It works out in the end,
> as far as the build is concerned, but it still bugs me.
> 
> Does anyone object to the idea of a selected item automatically
> selecting its own dependencies?
> 
> For example, you would only need to specify one "select" directive in
> X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
> would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
> on what it needed.

That is highly desirable IMO.  Not having that is one of the things
that makes using 'select' "evil."

Have you looked at the code and given any thought to implementing this?

Thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 22:00 -0700, Randy Dunlap wrote:
> > For example, you would only need to specify one "select" directive in
> > X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
> > would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
> > on what it needed.
> 
> That is highly desirable IMO.  Not having that is one of the things
> that makes using 'select' "evil."
> 
> Have you looked at the code and given any thought to implementing this?
> 

I'd like to take a run at it. The only issue I foresee is what to do
about multiple OR dependencies. There are some kconfig options that
depend on at least one of a set of specified dependencies. For example,
is ARCH_SPARSEMEM_ENABLE selectable if only one of NUMA || EXPERIMENTAL
is selected? So do we abort, select one, or select all dependencies?

Maybe I'm misunderstanding the usage of || here though. I'm assuming
inclusive OR.

James
	/\V

Re: broken ACPI NUMA config option

[Randy Dunlap]

James C. Georgas wrote:
> On Sat, 2007-08-09 at 22:00 -0700, Randy Dunlap wrote:
>>> For example, you would only need to specify one "select" directive in
>>> X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
>>> would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
>>> on what it needed.
>> That is highly desirable IMO.  Not having that is one of the things
>> that makes using 'select' "evil."
>>
>> Have you looked at the code and given any thought to implementing this?
>>
> 
> I'd like to take a run at it. The only issue I foresee is what to do
> about multiple OR dependencies. There are some kconfig options that
> depend on at least one of a set of specified dependencies. For example,
> is ARCH_SPARSEMEM_ENABLE selectable if only one of NUMA || EXPERIMENTAL
> is selected? So do we abort, select one, or select all dependencies?

It's a logical OR, meaning one or more of them is enabled.

I expect that there are some places that enabling all dependencies
would very much be the wrong thing to do, and choosing only one is
just a wild guess, so it looks like you would have to abort, with a
helpful message.

> Maybe I'm misunderstanding the usage of || here though. I'm assuming
> inclusive OR.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:09 -0700, Randy Dunlap wrote:
> On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
> 
> > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> > automatically, but ACPI is not selected automatically. This causes
> > ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> > symbols.
> 
> exactly what kernel version??
> 
> 

It's 2.6.22.6. I'm thinking a fix would be to add "select PM" to
X86_64_ACPI_NUMA.

I'm also thinking that maybe K8_NUMA should be changed from "depends on
PCI" to "select PCI", like X86_64_ACPI_NUMA is. That would fix the
pseudo dependency they have between them (i.e. selecting
X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA
visible, because its PCI dependency is now satisfied).

James
	/\V

Re: broken ACPI NUMA config option

[Andi Kleen]

"James C. Georgas" <jgeorgas@georgas.ca> writes:
> 
> It's 2.6.22.6. I'm thinking a fix would be to add "select PM" to
> X86_64_ACPI_NUMA.
> 
> I'm also thinking that maybe K8_NUMA should be changed from "depends on
> PCI" to "select PCI", like X86_64_ACPI_NUMA is. That would fix the
> pseudo dependency they have between them (i.e. selecting
> X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA
> visible, because its PCI dependency is now satisfied).

Sounds reasonable. Can you please submit a tested patch with proper
description and Signed-off-by lines?

-Andi

[PATCH] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options

[James C. Georgas]

On Sun, 2007-09-09 at 11:07 +0200, Andi Kleen wrote:
> "James C. Georgas" <jgeorgas@georgas.ca> writes:
> > 
> > It's 2.6.22.6. I'm thinking a fix would be to add "select PM" to
> > X86_64_ACPI_NUMA.
> > 
> > I'm also thinking that maybe K8_NUMA should be changed from "depends on
> > PCI" to "select PCI", like X86_64_ACPI_NUMA is. That would fix the
> > pseudo dependency they have between them (i.e. selecting
> > X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA
> > visible, because its PCI dependency is now satisfied).
> 
> Sounds reasonable. Can you please submit a tested patch with proper
> description and Signed-off-by lines?
> 
> -Andi

How's this?


>From 6febbd64aaca5d54487d8f9df4949001e0fc4ec6 Mon Sep 17 00:00:00 2001
From: James C. Georgas <jgeorgas@georgas.ca>
Date: Sun, 9 Sep 2007 08:27:46 -0400
Subject: [PATCH] Signed-off-by: James C. Georgas <jgeorgas@georgas.ca>

Changed K8_NUMA from "depends on PCI" to "select PCI", like X86_64_ACPI_NUMA is. This fixes the pseudo dependency between X86_64_ACPI_NUMA and K8_NUMA (i.e. selecting X86_64_ACPI_NUMA would cause PCI to be selected, which then made K8_NUMA visible, because its PCI dependency was now satisfied).
---
 arch/x86_64/Kconfig |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index ffa0364..bdeeb25 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -357,7 +357,8 @@ config NUMA
 
 config K8_NUMA
        bool "Old style AMD Opteron NUMA detection"
-       depends on NUMA && PCI
+       depends on NUMA
+       select PCI
        default y
        help
         Enable K8 NUMA node topology detection.  You should say Y here if
-- 
1.5.1.6

Re: [PATCH] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options

[Andi Kleen]

On Sun, Sep 09, 2007 at 09:19:05AM -0400, James C. Georgas wrote:
> On Sun, 2007-09-09 at 11:07 +0200, Andi Kleen wrote:
> > "James C. Georgas" <jgeorgas@georgas.ca> writes:
> > > 
> > > It's 2.6.22.6. I'm thinking a fix would be to add "select PM" to
> > > X86_64_ACPI_NUMA.
> > > 
> > > I'm also thinking that maybe K8_NUMA should be changed from "depends on
> > > PCI" to "select PCI", like X86_64_ACPI_NUMA is. That would fix the
> > > pseudo dependency they have between them (i.e. selecting
> > > X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA
> > > visible, because its PCI dependency is now satisfied).
> > 
> > Sounds reasonable. Can you please submit a tested patch with proper
> > description and Signed-off-by lines?
> > 
> > -Andi
> 
> How's this?

Thanks. How about a fix for the other problem (ACPI_NUMA- PM) too?

-Andi

Re: [PATCH] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options

[James C. Georgas]

On Sun, 2007-09-09 at 15:46 +0200, Andi Kleen wrote:

> Thanks. How about a fix for the other problem (ACPI_NUMA- PM) too?
> 

I don't want to just hard-select it until I understand what happened
between 2.6.22.6 and current git to make ACPI selectable without PM.

Personally, I think ACPI should be independent of PM anyway (at least as
it is displayed and selectable in the user interface. Obviously there
may be functional relationships between them). There is a "C" in ACPI,
after all, and some of that "C" doesn't really have anything to do with
power management.

James
	/\

Re: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
> On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote:
> 
> > On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
> > 
> > > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly)
selected
> > > automatically, but ACPI is not selected automatically. This causes
> > > ACPI_NUMA to not be built, and the kernel compile fails with
unresolved
> > > symbols.
> > 
> > exactly what kernel version??
> > 
> 
> 2.6.23-rc5-git1 builds for me when I follow those steps...
> except for some Section mismatch warnings.

What is the git project path name for the 2.6.23rc branch, if I wanted
to clone it, to keep up to date?

James
	/\V

Re: broken ACPI NUMA config option

[Sam Ravnborg]

Hi James.

> > 2.6.23-rc5-git1 builds for me when I follow those steps...
> > except for some Section mismatch warnings.
> 
> What is the git project path name for the 2.6.23rc branch, if I wanted
> to clone it, to keep up to date?

You can find the -gitN trees at frontpage og www.kernel.org.
If you prefer git access look for the project named: linux-2.6-snaps
on git.kernel.org

	Sam