Re: broken ACPI NUMA config option

2007-09-09 Thread 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 ***
-
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/


Re: broken ACPI NUMA config option

2007-09-09 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-09 Thread Andi Kleen
"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
-
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/


Re: broken ACPI NUMA config option

2007-09-09 Thread 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
-
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/


Re: broken ACPI NUMA config option

2007-09-09 Thread 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
-
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/


Re: broken ACPI NUMA config option

2007-09-09 Thread Andi Kleen
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
-
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/


Re: broken ACPI NUMA config option

2007-09-09 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-09 Thread 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 ***
-
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/


Re: broken ACPI NUMA config option

2007-09-08 Thread 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 ***
-
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/


Re: broken ACPI NUMA config option

2007-09-08 Thread Yinghai Lu
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
-
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/


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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
> > 
> > 
> > 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 ***
-
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/


Re: broken ACPI NUMA config option

2007-09-08 Thread 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
>   
> 
> 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/


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


broken ACPI NUMA config option

2007-09-08 Thread 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


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

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


broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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 ***
-
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/


Re: broken ACPI NUMA config option

2007-09-08 Thread 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 [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 ***
-
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/


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread 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

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


Re: broken ACPI NUMA config option

2007-09-08 Thread Yinghai Lu
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
-
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/


Re: broken ACPI NUMA config option

2007-09-08 Thread 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 ***
-
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/