linux-next: x86 tree build failure

linux-next: x86 tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (x86_64 allmodconfig) failed like this:

arch/x86/kernel/k8.c:20: error: 'PCI_DEVICE_ID_AMD_10H_NB_MISC' undeclared here (not in a function)

Introduced by commit cf169702ba6928cee9d4f4adf3e932b643b8db7a ("x86,
gart: add detection of AMD family 0x11 northbridges").  I applied the
following patch.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Sep 2008 09:52:19 +1000
Subject: [PATCH] x86: fix arch/x86/kernel/k8.c

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/k8.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/k8.c b/arch/x86/kernel/k8.c
index 304d8ba..3f5b832 100644
--- a/arch/x86/kernel/k8.c
+++ b/arch/x86/kernel/k8.c
@@ -17,7 +17,7 @@ static u32 *flush_words;
 
 struct pci_device_id k8_nb_ids[] = {
 	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB_MISC) },
-	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_10H_NB_MISC) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x1203) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_11H_NB_MISC) },
 	{}
 };
-- 
1.5.6.3

Re: linux-next: x86 tree build failure

[Joerg Roedel]

Hi Stephen,

do you have these commits in next/master already? I tried to find out
why it fails (the build failure is weird because
PCI_DEVICE_ID_AMD_10H_NB_MISC and PCI_DEVICE_ID_AMD_11H_NB_MISC
are defined in the same place in tip/master).

Joerg

On Fri, Sep 12, 2008 at 09:56:18AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> arch/x86/kernel/k8.c:20: error: 'PCI_DEVICE_ID_AMD_10H_NB_MISC' undeclared here (not in a function)
> 
> Introduced by commit cf169702ba6928cee9d4f4adf3e932b643b8db7a ("x86,
> gart: add detection of AMD family 0x11 northbridges").  I applied the
> following patch.
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 12 Sep 2008 09:52:19 +1000
> Subject: [PATCH] x86: fix arch/x86/kernel/k8.c
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/kernel/k8.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/kernel/k8.c b/arch/x86/kernel/k8.c
> index 304d8ba..3f5b832 100644
> --- a/arch/x86/kernel/k8.c
> +++ b/arch/x86/kernel/k8.c
> @@ -17,7 +17,7 @@ static u32 *flush_words;
>  
>  struct pci_device_id k8_nb_ids[] = {
>  	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB_MISC) },
> -	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_10H_NB_MISC) },
> +	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x1203) },
>  	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_11H_NB_MISC) },
>  	{}
>  };
> -- 
> 1.5.6.3
> 
> 

-- 
           |           AMD Saxony Limited Liability Company & Co. KG
 Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System    |                  Register Court Dresden: HRA 4896
 Research  |              General Partner authorized to represent:
 Center    |             AMD Saxony LLC (Wilmington, Delaware, US)
           | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

Re: linux-next: x86 tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

Hi Joerg,

On Fri, 12 Sep 2008 08:05:27 +0200 Joerg Roedel <joerg.roedel@amd.com> wrote:
>
> do you have these commits in next/master already? I tried to find out

Not until tomorrow some time, sorry.

> why it fails (the build failure is weird because
> PCI_DEVICE_ID_AMD_10H_NB_MISC and PCI_DEVICE_ID_AMD_11H_NB_MISC
> are defined in the same place in tip/master).

tip/master has more trees merged than the x86 tree (and indeed
PCI_DEVICE_ID_AMD_10H_NB_MISC turns up in the timers tree).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: x86 tree build failure

[Joerg Roedel]

On Fri, Sep 12, 2008 at 05:31:41PM +1000, Stephen Rothwell wrote:
> Hi Joerg,
> 
> On Fri, 12 Sep 2008 08:05:27 +0200 Joerg Roedel <joerg.roedel@amd.com> wrote:
> >
> > do you have these commits in next/master already? I tried to find out
> 
> Not until tomorrow some time, sorry.
> 
> > why it fails (the build failure is weird because
> > PCI_DEVICE_ID_AMD_10H_NB_MISC and PCI_DEVICE_ID_AMD_11H_NB_MISC
> > are defined in the same place in tip/master).
> 
> tip/master has more trees merged than the x86 tree (and indeed
> PCI_DEVICE_ID_AMD_10H_NB_MISC turns up in the timers tree).

Ah ok, there is the problem, I see. Thanks.

Joerg



-- 
           |           AMD Saxony Limited Liability Company & Co. KG
 Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System    |                  Register Court Dresden: HRA 4896
 Research  |              General Partner authorized to represent:
 Center    |             AMD Saxony LLC (Wilmington, Delaware, US)
           | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

Re: linux-next: x86 tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Joerg,
> 
> On Fri, 12 Sep 2008 08:05:27 +0200 Joerg Roedel <joerg.roedel@amd.com> wrote:
> >
> > do you have these commits in next/master already? I tried to find out
> 
> Not until tomorrow some time, sorry.
> 
> > why it fails (the build failure is weird because
> > PCI_DEVICE_ID_AMD_10H_NB_MISC and PCI_DEVICE_ID_AMD_11H_NB_MISC
> > are defined in the same place in tip/master).
> 
> tip/master has more trees merged than the x86 tree (and indeed 
> PCI_DEVICE_ID_AMD_10H_NB_MISC turns up in the timers tree).

hm, but linux-next should have the timers tree merged too. So how come 
you triggered this build error?

	Ingo

Re: linux-next: x86 tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

Hi Ingo,

On Fri, 12 Sep 2008 10:30:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> hm, but linux-next should have the timers tree merged too. So how come 
> you triggered this build error?

Because (as I say in every daily announcement) I build the tree between
each merge.  This is because each (sub)tree that is merged into
linux-next is meant to be fairly independent (or have dependencies I know
about) and be ready (except for interactions with other trees) to be
merged by Linus when he opens the next merge window.  Also, I hope that
the linux-next tree each day is mostly bisectable (between stable and
master) so people can find bugs in it if necessary.

I assumed that the various TIP trees are fairly independent because you
do internal merges.

You can see the merge order by looking in the merge.log file in the Next
directory of the linux-next tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: x86 tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/char/agp/uninorth-agp.c:541: error: unknown field 'agp_destroy_paged' specified in initializer

Caused by commit 5f310b63781f6777bf4e812570560ec0f8ea42d8 ("agp: enable optimized agp_alloc_pages methods").  A simple typo ...

I applied the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 Aug 2008 20:16:07 +1000
Subject: [PATCH] agp: fix typo in uninorth-agp

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/char/agp/uninorth-agp.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 2accc97..0f004b6 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -538,7 +538,7 @@ const struct agp_bridge_driver u3_agp_driver = {
 	.agp_alloc_page		= agp_generic_alloc_page,
 	.agp_alloc_pages	= agp_generic_alloc_pages,
 	.agp_destroy_page	= agp_generic_destroy_page,
-	.agp_destroy_paged	= agp_generic_destroy_pages,
+	.agp_destroy_pages	= agp_generic_destroy_pages,
 	.agp_type_to_mask_type  = agp_generic_type_to_mask_type,
 	.cant_use_aperture	= true,
 	.needs_scratch_page	= true,
-- 
1.5.6.3

Re: linux-next: x86 tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/char/agp/uninorth-agp.c:541: error: unknown field 'agp_destroy_paged' specified in initializer
> 
> Caused by commit 5f310b63781f6777bf4e812570560ec0f8ea42d8 ("agp: 
> enable optimized agp_alloc_pages methods").  A simple typo ...
> 
> I applied the following patch.

applied to tip/x86/pat - thanks Stephen!

	Ingo

linux-next: x86 tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

Hi all,

Today's linux-next build (x86_64 allmodconfig) failed like this:

arch/x86/kernel/syscall_64.c:27: error: array index in initializer exceeds array bounds
arch/x86/kernel/syscall_64.c:27: error: (near initialization for 'sys_call_table')
arch/x86/kernel/syscall_64.c:27: warning: excess elements in array initializer
arch/x86/kernel/syscall_64.c:27: warning: (near initialization for 'sys_call_table')

Reverting commit aa27f95867447916d97c7aa6e5422ff6518630dd ("x86:
consolidate header guards") makes it build ok.  I found that hard to
believe, so I undid the revert and it fails again.

gcc is x86_64-unknown-linux-gnu-gcc (GCC) 4.0.2 cross built on a powerpc host.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: x86 tree build failure

[Vegard Nossum]

On Thu, Jul 17, 2008 at 4:07 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> arch/x86/kernel/syscall_64.c:27: error: array index in initializer exceeds array bounds
> arch/x86/kernel/syscall_64.c:27: error: (near initialization for 'sys_call_table')
> arch/x86/kernel/syscall_64.c:27: warning: excess elements in array initializer
> arch/x86/kernel/syscall_64.c:27: warning: (near initialization for 'sys_call_table')
>
> Reverting commit aa27f95867447916d97c7aa6e5422ff6518630dd ("x86:
> consolidate header guards") makes it build ok.  I found that hard to
> believe, so I undid the revert and it fails again.

Oh, this is in next already?

The basic problem is that I completely overlooked the fact that some
headers use the guards of _other_ headers in #if-checks. I think we
should drop the consolidations completely until I have fixed the
script to replace the header guard names which are used in other files
as well. I'm sorry :-/


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

Re: linux-next: x86 tree build failure

[Ingo Molnar]

* Vegard Nossum <vegard.nossum@gmail.com> wrote:

> On Thu, Jul 17, 2008 at 4:07 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi all,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > arch/x86/kernel/syscall_64.c:27: error: array index in initializer exceeds array bounds
> > arch/x86/kernel/syscall_64.c:27: error: (near initialization for 'sys_call_table')
> > arch/x86/kernel/syscall_64.c:27: warning: excess elements in array initializer
> > arch/x86/kernel/syscall_64.c:27: warning: (near initialization for 'sys_call_table')
> >
> > Reverting commit aa27f95867447916d97c7aa6e5422ff6518630dd ("x86:
> > consolidate header guards") makes it build ok.  I found that hard to
> > believe, so I undid the revert and it fails again.
> 
> Oh, this is in next already?
> 
> The basic problem is that I completely overlooked the fact that some 
> headers use the guards of _other_ headers in #if-checks. I think we 
> should drop the consolidations completely until I have fixed the 
> script to replace the header guard names which are used in other files 
> as well. I'm sorry :-/

ok, dropped them from the -next integration rules. Stephen, can you use 
the previous version of the x86 branch, or should i reintegrate it now?

	Ingo

Re: linux-next: x86 tree build failure

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > The basic problem is that I completely overlooked the fact that some 
> > headers use the guards of _other_ headers in #if-checks. I think we 
> > should drop the consolidations completely until I have fixed the 
> > script to replace the header guard names which are used in other 
> > files as well. I'm sorry :-/
> 
> ok, dropped them from the -next integration rules. Stephen, can you 
> use the previous version of the x86 branch, or should i reintegrate it 
> now?

ok, i fixed it up in tip/auto-x86-next and pushed it out.

	Ingo

Re: linux-next: x86 tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

Hi Ingo,

On Fri, 18 Jul 2008 22:12:06 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > The basic problem is that I completely overlooked the fact that some 
> > > headers use the guards of _other_ headers in #if-checks. I think we 
> > > should drop the consolidations completely until I have fixed the 
> > > script to replace the header guard names which are used in other 
> > > files as well. I'm sorry :-/
> > 
> > ok, dropped them from the -next integration rules. Stephen, can you 
> > use the previous version of the x86 branch, or should i reintegrate it 
> > now?
> 
> ok, i fixed it up in tip/auto-x86-next and pushed it out.

Just for future reference:  I rarely do linux-next builds on weekends (my
time) ...

Thanks for fixing this up.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: x86 tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

Hi all,

Today's linux-next build (x86_64 allmodconfig) after merging the x86 tree
failed like this:

In file included from arch/x86/kernel/setup_64.c:34:
include/linux/acpi.h:97:1: warning: "NR_NODE_MEMBLKS" redefined
In file included from include/acpi/platform/aclinux.h:59,
                 from include/acpi/platform/acenv.h:140,
                 from include/acpi/acpi.h:54,
                 from include/linux/acpi.h:39,
                 from arch/x86/kernel/setup_64.c:34:
include2/asm/acpi.h:165:1: warning: this is the location of the previous definition

NR_NODE_MEMBLKS is defined in linux/acpi.h if CONFIG_HAVE_ARCH_PARSE_SRAT
is defined and in asm-x86/acpi.h if CONFIG_ACPI_NUMA and CONFIG_X86_64
are defined ...

Lots of the above, as well as:

arch/x86/mm/srat_64.c:101: error: syntax error before 'do'
arch/x86/mm/srat_64.c:108: error: syntax error before 'do'
arch/x86/mm/srat_64.c:113: error: syntax error before 'if'

and it went down hill from here ...

srat_64.c is built if CONFIG_X86_32 is *not* 'y' and CONFIG_ACPI_NUMA is
'y' while in include/linux/acpi.h, acpi_numa_slit_init,
acpi_numa_processor_affinity_init, acpi_numa_memory_affinity_init and
acpi_numa_arch_fixup are all macros if CONFIG_HAVE_ARCH_PARSE_SRAT is
defined.

So we have CONFIG_X86_64, CONFIG_ACPI_NUMA and
CONFIG_HAVE_ARCH_PARSE_SRAT all defined.

I have no idea how (or time) to fix this, so the x86 tree is dropped for
today.  If you guys are going to auto generate a tree for me each day,
then you need to test build it a bit, please.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: x86 tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next build (x86_64 allmodconfig) after merging the x86 tree
> failed like this:
> 
> In file included from arch/x86/kernel/setup_64.c:34:
> include/linux/acpi.h:97:1: warning: "NR_NODE_MEMBLKS" redefined
> In file included from include/acpi/platform/aclinux.h:59,
>                  from include/acpi/platform/acenv.h:140,
>                  from include/acpi/acpi.h:54,
>                  from include/linux/acpi.h:39,
>                  from arch/x86/kernel/setup_64.c:34:
> include2/asm/acpi.h:165:1: warning: this is the location of the previous definition
> 
> NR_NODE_MEMBLKS is defined in linux/acpi.h if CONFIG_HAVE_ARCH_PARSE_SRAT
> is defined and in asm-x86/acpi.h if CONFIG_ACPI_NUMA and CONFIG_X86_64
> are defined ...

that's not really the x86 tree's fault, i've been carrying the fix for 
that problem in tip/out-of-tree for 1.5 months:

| commit d94325315f241f86bd07a2ce113cbf28dc98de72
| Author: Ingo Molnar <mingo@elte.hu>
| Date:   Thu May 1 09:51:47 2008 +0000
|
|     acpi-acpi_numa_init-build-fix
|
|     x86.git testing found the following build error on latest -git:
|
|     drivers/acpi/numa.c: In function 'acpi_numa_init':
|     drivers/acpi/numa.c:226: error: 'NR_NODE_MEMBLKS' undeclared (first use in
|     drivers/acpi/numa.c:226: error: (Each undeclared identifier is reported onl
|     drivers/acpi/numa.c:226: error: for each function it appears in.)

> Lots of the above, as well as:
> 
> arch/x86/mm/srat_64.c:101: error: syntax error before 'do'
> arch/x86/mm/srat_64.c:108: error: syntax error before 'do'
> arch/x86/mm/srat_64.c:113: error: syntax error before 'if'
> 
> and it went down hill from here ...
> 
> srat_64.c is built if CONFIG_X86_32 is *not* 'y' and CONFIG_ACPI_NUMA is
> 'y' while in include/linux/acpi.h, acpi_numa_slit_init,
> acpi_numa_processor_affinity_init, acpi_numa_memory_affinity_init and
> acpi_numa_arch_fixup are all macros if CONFIG_HAVE_ARCH_PARSE_SRAT is
> defined.
> 
> So we have CONFIG_X86_64, CONFIG_ACPI_NUMA and
> CONFIG_HAVE_ARCH_PARSE_SRAT all defined.
> 
> I have no idea how (or time) to fix this, so the x86 tree is dropped for
> today.  [...]

hm, i guess you mean you went back to the previous version?

> [...] If you guys are going to auto generate a tree for me each day, 
> then you need to test build it a bit, please.

i _did_ test it prior pushing it out and it passed 30 build+boot 
iterations until it ran into that tip/out-of-tree fix. I decided not to 
add it to auto-x86-next because it does not belong into the x86 tree.

you could also revert:

| commit 6ca7b49a8d6ca765426540c8902d89f1345b14af
| Author: Yinghai Lu <yhlu.kernel@gmail.com>
| Date:   Fri Jun 6 19:54:25 2008 -0700
|
|    x86: add SRAT parsing to 64-bit

which makes that acpi build bug not trigger in allmodconfig. But this 
just obscures the bug.

	Ingo

Re: linux-next: x86 tree build failure

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > NR_NODE_MEMBLKS is defined in linux/acpi.h if 
> > CONFIG_HAVE_ARCH_PARSE_SRAT is defined and in asm-x86/acpi.h if 
> > CONFIG_ACPI_NUMA and CONFIG_X86_64 are defined ...
> 
> that's not really the x86 tree's fault, i've been carrying the fix for 
> that problem in tip/out-of-tree for 1.5 months:
> 
> | commit d94325315f241f86bd07a2ce113cbf28dc98de72
> | Author: Ingo Molnar <mingo@elte.hu>
> | Date:   Thu May 1 09:51:47 2008 +0000
> |
> |     acpi-acpi_numa_init-build-fix
> |
> |     x86.git testing found the following build error on latest -git:
> |
> |     drivers/acpi/numa.c: In function 'acpi_numa_init':
> |     drivers/acpi/numa.c:226: error: 'NR_NODE_MEMBLKS' undeclared (first use in
> |     drivers/acpi/numa.c:226: error: (Each undeclared identifier is reported onl
> |     drivers/acpi/numa.c:226: error: for each function it appears in.)

note, if you cherry-pick that, you'll also need:

| commit aca9de453911d095a9701ee6ebbae7fd3d6c7c1e
| Author: Russ Anderson <rja@sgi.com>
| Date:   Fri May 16 10:02:06 2008 -0500
|
|     acpi: fix boot breakage on Altix

	Ingo

Re: linux-next: x86 tree build failure

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > | commit d94325315f241f86bd07a2ce113cbf28dc98de72
> > | Author: Ingo Molnar <mingo@elte.hu>
> > | Date:   Thu May 1 09:51:47 2008 +0000
> > |
> > |     acpi-acpi_numa_init-build-fix
> > |
> > |     x86.git testing found the following build error on latest -git:
> > |
> > |     drivers/acpi/numa.c: In function 'acpi_numa_init':
> > |     drivers/acpi/numa.c:226: error: 'NR_NODE_MEMBLKS' undeclared (first use in
> > |     drivers/acpi/numa.c:226: error: (Each undeclared identifier is reported onl
> > |     drivers/acpi/numa.c:226: error: for each function it appears in.)

btw., googling for "error: 'NR_NODE_MEMBLKS' undeclared" jumps straight 
to the patch i posted to lkml long ago.

> note, if you cherry-pick that, you'll also need:
> 
> | commit aca9de453911d095a9701ee6ebbae7fd3d6c7c1e
> | Author: Russ Anderson <rja@sgi.com>
> | Date:   Fri May 16 10:02:06 2008 -0500
> |
> |     acpi: fix boot breakage on Altix

i double-checked that cherry-picking these two out-of-x86-scope fixes 
from a month ago (which we found during -tip build testing) into 
auto-x86-next gets allmodconfig going.

I'm reluctant to permanently put them into the x86 branches though, as 
they are 'out of scope' of arch/x86 and would make the branch eligible 
to be 'pruned' out of linux-next.

the two fixes are attached below.

	Ingo

---------------------->
commit d94325315f241f86bd07a2ce113cbf28dc98de72
Author: Ingo Molnar <mingo@elte.hu>
Date:   Thu May 1 09:51:47 2008 +0000

    acpi-acpi_numa_init-build-fix
    
    x86.git testing found the following build error on latest -git:
    
     drivers/acpi/numa.c: In function 'acpi_numa_init':
     drivers/acpi/numa.c:226: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)
     drivers/acpi/numa.c:226: error: (Each undeclared identifier is reported only once
     drivers/acpi/numa.c:226: error: for each function it appears in.)
    
    with this config:
    
     http://redhat.com/~mingo/misc/config-Wed_Apr_30_22_42_42_CEST_2008.bad
    
    i suspect we dont want SRAT parsing when CONFIG_HAVE_ARCH_PARSE_SRAT
    is unset - but the fix looks a bit ugly. Perhaps we should define
    NR_NODE_MEMBLKS even in this case and just let the code fall back
    to some sane behavior?
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 5d59cb3..8cab8c5 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -176,6 +176,7 @@ acpi_parse_processor_affinity(struct acpi_subtable_header * header,
 	return 0;
 }
 
+#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
 static int __init
 acpi_parse_memory_affinity(struct acpi_subtable_header * header,
 			   const unsigned long end)
@@ -193,6 +194,7 @@ acpi_parse_memory_affinity(struct acpi_subtable_header * header,
 
 	return 0;
 }
+#endif
 
 static int __init acpi_parse_srat(struct acpi_table_header *table)
 {
@@ -221,9 +223,11 @@ int __init acpi_numa_init(void)
 	if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
 		acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
 				      acpi_parse_processor_affinity, NR_CPUS);
+#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
 		acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
 				      acpi_parse_memory_affinity,
 				      NR_NODE_MEMBLKS);
+#endif
 	}
 
 	/* SLIT: System Locality Information Table */

commit aca9de453911d095a9701ee6ebbae7fd3d6c7c1e
Author: Russ Anderson <rja@sgi.com>
Date:   Fri May 16 10:02:06 2008 -0500

    acpi: fix boot breakage on Altix
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 16be414..1be94eb 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -60,6 +60,10 @@ config RWSEM_XCHGADD_ALGORITHM
 	bool
 	default y
 
+config HAVE_ARCH_PARSE_SRAT
+	bool
+	default y
+
 config ARCH_HAS_ILOG2_U32
 	bool
 	default n
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 41f7ce7..b426ac5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -93,7 +93,7 @@ int acpi_parse_mcfg (struct acpi_table_header *header);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
 
 /* the following four functions are architecture-dependent */
-#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
+#if defined(CONFIG_HAVE_ARCH_PARSE_SRAT) && !defined(NR_NODE_MEMBLKS)
 #define NR_NODE_MEMBLKS MAX_NUMNODES
 #define acpi_numa_slit_init(slit) do {} while (0)
 #define acpi_numa_processor_affinity_init(pa) do {} while (0)

Re: linux-next: x86 tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Hi Ingo,

On Tue, 17 Jun 2008 07:58:16 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> hm, i guess you mean you went back to the previous version?

No, I dropped it completely, but I will try to remember that idea for
next time.  It is back today and seems ok again.  Thanks for applying
those patches.

> which makes that acpi build bug not trigger in allmodconfig. But this 
> just obscures the bug.

So do the acpi guys need a push?  Can I help in that?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: x86 tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Tue, 17 Jun 2008 07:58:16 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > hm, i guess you mean you went back to the previous version?
> 
> No, I dropped it completely, but I will try to remember that idea for 
> next time. It is back today and seems ok again.  Thanks for applying 
> those patches.

well, note that those patches will go away on the next auto-x86-next 
iteration, as they touch pure acpi code with no direct x86 component. 
Please keep track of them separately.

Note that there's about half a dozen other potential bugs i've already 
fixed in -tip and which are in various stages of getting propagated to 
other trees. You might want to start tracking tip/out-of-tree, that's a 
laundry list of (sometimes questionable) convenience fixes and hacks.

( If you start tracking tip/out-of-tree: i'm willing to drop any patch
  in there in favor of an existing better fix [even if that fix is not 
  well-tested], but i'm not willing to drop anything in there on the 
  pure grounds of it crossing maintenance boundaries. I need those fixes 
  for -tip testing - and they cross maintenance boundaries, that's why 
  it's called tip/out-of-tree - it's fixes not covered by the topics in 
  -tip itself. )

> > which makes that acpi build bug not trigger in allmodconfig. But 
> > this just obscures the bug.
> 
> So do the acpi guys need a push?  Can I help in that?

I've Cc:-ed Len. The recap, there was a pre-existing ACPI build problem, 
which was made more prominent via this change:

| commit 6ca7b49a8d6ca765426540c8902d89f1345b14af
| Author: Yinghai Lu <yhlu.kernel@gmail.com>
| Date:   Fri Jun 6 19:54:25 2008 -0700
|
|    x86: add SRAT parsing to 64-bit
|
|    parse the SRAT on 64-bit unconditionally.

as that ACPI build problem now triggers an an allmodconfig x86 64-bit 
build. Would be nice if Len could have a look and pick up (or NAK/fix) 
the two patches below from Russ Anderson and me. The ia64 fix is there 
because ia64 really wants to do SRAT parsing to be bootable.

	Ingo

---------------------->
commit d94325315f241f86bd07a2ce113cbf28dc98de72
Author: Ingo Molnar <mingo@elte.hu>
Date:   Thu May 1 09:51:47 2008 +0000

    acpi: acpi numa init build fix
    
    x86.git testing found the following build error on latest -git:
    
     drivers/acpi/numa.c: In function 'acpi_numa_init':
     drivers/acpi/numa.c:226: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)
     drivers/acpi/numa.c:226: error: (Each undeclared identifier is reported only once
     drivers/acpi/numa.c:226: error: for each function it appears in.)
    
    with this config:
    
     http://redhat.com/~mingo/misc/config-Wed_Apr_30_22_42_42_CEST_2008.bad
    
    i suspect we dont want SRAT parsing when CONFIG_HAVE_ARCH_PARSE_SRAT
    is unset - but the fix looks a bit ugly. Perhaps we should define
    NR_NODE_MEMBLKS even in this case and just let the code fall back
    to some sane behavior?
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 5d59cb3..8cab8c5 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -176,6 +176,7 @@ acpi_parse_processor_affinity(struct acpi_subtable_header * header,
 	return 0;
 }
 
+#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
 static int __init
 acpi_parse_memory_affinity(struct acpi_subtable_header * header,
 			   const unsigned long end)
@@ -193,6 +194,7 @@ acpi_parse_memory_affinity(struct acpi_subtable_header * header,
 
 	return 0;
 }
+#endif
 
 static int __init acpi_parse_srat(struct acpi_table_header *table)
 {
@@ -221,9 +223,11 @@ int __init acpi_numa_init(void)
 	if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
 		acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
 				      acpi_parse_processor_affinity, NR_CPUS);
+#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
 		acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
 				      acpi_parse_memory_affinity,
 				      NR_NODE_MEMBLKS);
+#endif
 	}
 
 	/* SLIT: System Locality Information Table */

commit aca9de453911d095a9701ee6ebbae7fd3d6c7c1e
Author: Russ Anderson <rja@sgi.com>
Date:   Fri May 16 10:02:06 2008 -0500

    acpi: fix boot breakage on Altix
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 16be414..1be94eb 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -60,6 +60,10 @@ config RWSEM_XCHGADD_ALGORITHM
 	bool
 	default y
 
+config HAVE_ARCH_PARSE_SRAT
+	bool
+	default y
+
 config ARCH_HAS_ILOG2_U32
 	bool
 	default n
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 41f7ce7..b426ac5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -93,7 +93,7 @@ int acpi_parse_mcfg (struct acpi_table_header *header);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
 
 /* the following four functions are architecture-dependent */
-#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
+#if defined(CONFIG_HAVE_ARCH_PARSE_SRAT) && !defined(NR_NODE_MEMBLKS)
 #define NR_NODE_MEMBLKS MAX_NUMNODES
 #define acpi_numa_slit_init(slit) do {} while (0)
 #define acpi_numa_processor_affinity_init(pa) do {} while (0)

Re: linux-next: x86 tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

Hi All,

On Tue, 17 Jun 2008 13:46:15 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) after merging the x86 tree
> failed like this:
> 
> In file included from arch/x86/kernel/setup_64.c:34:
> include/linux/acpi.h:97:1: warning: "NR_NODE_MEMBLKS" redefined
> In file included from include/acpi/platform/aclinux.h:59,
>                  from include/acpi/platform/acenv.h:140,
>                  from include/acpi/acpi.h:54,
>                  from include/linux/acpi.h:39,
>                  from arch/x86/kernel/setup_64.c:34:
> include2/asm/acpi.h:165:1: warning: this is the location of the previous definition
> 
> NR_NODE_MEMBLKS is defined in linux/acpi.h if CONFIG_HAVE_ARCH_PARSE_SRAT
> is defined and in asm-x86/acpi.h if CONFIG_ACPI_NUMA and CONFIG_X86_64
> are defined ...
> 
> Lots of the above, as well as:
> 
> arch/x86/mm/srat_64.c:101: error: syntax error before 'do'
> arch/x86/mm/srat_64.c:108: error: syntax error before 'do'
> arch/x86/mm/srat_64.c:113: error: syntax error before 'if'

This came back today (as Ingo said it would) to fix it, I have added the
following patches to linux-next:

acpi-acpi_numa_init-build-fix
ia64, acpi: fix Altix boot breakage in ACPI
acpi: fix boot breakage on Altix

All these have been incorporated into the commit that merges the x86 tree
so bisection should not fail.

What you need to do now is plan how you are going to get this into Linus'
tree ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]