Skip to contentSkip to conversation

broken ACPI NUMA config option

PATCH In review James C. Georgas 4 participants 15 messages Sep 8, 2007 – Sep 9, 2007

lore
Share & tools
lore

James C. Georgas

author
#0 lore raw

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
author
#1 lore raw
Quoted 5 lines · James C. Georgas

Steps to reproduce:

make clean
make mrproper
make noallconfig

Excuse me; that should read allnoconfig, not noallconfig.

James

	/\V
author
#2 lore raw
In reply to James C. Georgas
Quoted 5 lines · 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.

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
#3 lore raw
In reply to James C. Georgas
Quoted 4 lines · 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??

Quoted 15 lines

Steps to reproduce:

	make clean
	make mrproper
	make noallconfig

	select SMP
	select NUMA
	select X86_64_ACPI_NUMA

	make
	<boom>

results:

Quoted 10 lines
	  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 ***

#4 lore raw
Quoted 9 lines · On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote:
Quoted 4 lines · 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.

Quoted 27 lines
Quoted 15 lines

Steps to reproduce:

	make clean
	make mrproper
	make noallconfig

	select SMP
	select NUMA
	select X86_64_ACPI_NUMA

	make
	<boom>

results:

Quoted 10 lines
	  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
Quoted 9 lines

---
~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 [email protected]
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 ***

author
#5 lore raw
Quoted 3 lines · Randy Dunlap

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
#6 lore raw
Quoted 14 lines · James C. Georgas
Quoted 3 lines · Randy Dunlap

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.

Quoted 7 lines

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

#7 lore raw
In reply to James C. Georgas
Quoted 14 lines · On Sat, 08 Sep 2007 23:48:56 -0400 James C. Georgas wrote:
Quoted 3 lines · Randy Dunlap

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.

Quoted 7 lines

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

author
#8 lore raw
Quoted 10 lines · Randy Dunlap
Quoted 4 lines

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
#9 lore raw
Quoted 8 lines · James C. Georgas
Quoted 7 lines · Randy Dunlap
Quoted 4 lines

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

Quoted 8 lines
Quoted 2 lines

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.

Quoted 2 lines

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

Signature · 2 lines
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
author
#10 lore raw
In reply to Randy Dunlap
Quoted 10 lines · Randy Dunlap
Quoted 4 lines · 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
#11 lore raw
Quoted 9 lines · James C. Georgas

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

author
#12 lore raw

PATCH 1/1 KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options

Quoted 11 lines · Andi Kleen
Quoted 9 lines · James C. Georgas

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

Quoted 4 lines

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

-Andi

How's this?

Quoted 1 line

From 6febbd64aaca5d54487d8f9df4949001e0fc4ec6 Mon Sep 17 00:00:00 2001

From: James C. Georgas <[email protected]>
Date: Sun, 9 Sep 2007 08:27:46 -0400
Subject: [PATCH] Signed-off-by: James C. Georgas <[email protected]>

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(-)
arch/x86_64/Kconfig +2 -1
index ffa0364..bdeeb25 100644
@@ -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
Signature · 1 line
1.5.1.6
#13 lore raw

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

Quoted 12 lines · James C. Georgas
Quoted 11 lines · Andi Kleen
Quoted 9 lines · James C. Georgas

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

Quoted 6 lines
Quoted 4 lines

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

author
#14 lore raw

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

Quoted 2 lines · Andi Kleen

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

	/\