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
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
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
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 ***
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 [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 ***
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
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
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
On 9/8/07, James C. Georgas <[email protected]> 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
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 ***
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 http://www.kernel.org.
If you prefer git access look for the project named: linux-2.6-snaps
on git.kernel.org
Sam
"James C. Georgas" <[email protected]> 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
On Sun, 2007-09-09 at 11:07 +0200, Andi Kleen wrote:
> "James C. Georgas" <[email protected]> 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 <[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(-)
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
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
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" <[email protected]> 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
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 ***
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
/\