GENERIC build failure

GENERIC build failure

[David Mosberger]

According to this page:

  http://www.gelato.unsw.edu.au/kerncomp/

Generic kernel builds are still failing, due to some NUMA cruft.
I thought this was supposed to be fixed already.  Can someone
who cares about NUMA investigate?

	-d-avid

Re: GENERIC build failure

[Jesse Barnes]

This is fixed in Andrew's tree.  I'm not sure why Len hasn't pushed it
to Linus yet though.

The fix is a simple change of NR_MEMBLKS to NR_NODE_MEMBLKS.

Jesse

On Fri, Feb 13, 2004 at 01:33:36PM -0800, David Mosberger wrote:
> According to this page:
> 
>   http://www.gelato.unsw.edu.au/kerncomp/
> 
> Generic kernel builds are still failing, due to some NUMA cruft.
> I thought this was supposed to be fixed already.  Can someone
> who cares about NUMA investigate?
> 
> 	-d-avid
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GENERIC build failure

[David Mosberger]

Andrew,

Could you push this fix into Linus' tree?  I'd consider it urgent,
because we do want GENERIC configs to build out-of-the-box for 2.6.3.

Thanks,

	--david

>>>>> On Fri, 13 Feb 2004 13:51:05 -0800, jbarnes@sgi.com (Jesse Barnes) said:

  Jesse> This is fixed in Andrew's tree.  I'm not sure why Len hasn't
  Jesse> pushed it to Linus yet though.

  Jesse> The fix is a simple change of NR_MEMBLKS to NR_NODE_MEMBLKS.

  Jesse> Jesse

  Jesse> On Fri, Feb 13, 2004 at 01:33:36PM -0800, David Mosberger
  Jesse> wrote:
  >> According to this page:
  >> 
  >> http://www.gelato.unsw.edu.au/kerncomp/
  >> 
  >> Generic kernel builds are still failing, due to some NUMA cruft.
  >> I thought this was supposed to be fixed already.  Can someone who
  >> cares about NUMA investigate?
  >> 
  >> -d-avid
  >> -
  >> To unsubscribe from this list: send the line "unsubscribe
  >> linux-ia64" in the body of a message to majordomo@vger.kernel.org
  >> More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: GENERIC build failure

[Andrew Morton]

I dropped the patch because it's fixed in Len's tree.

If someone can send me a tested standalone patch then sure.

David Mosberger <davidm@napali.hpl.hp.com> wrote:
>
> Andrew,
> 
> Could you push this fix into Linus' tree?  I'd consider it urgent,
> because we do want GENERIC configs to build out-of-the-box for 2.6.3.
> 
> Thanks,
> 
> 	--david
> 
> >>>>> On Fri, 13 Feb 2004 13:51:05 -0800, jbarnes@sgi.com (Jesse Barnes) said:
> 
>   Jesse> This is fixed in Andrew's tree.  I'm not sure why Len hasn't
>   Jesse> pushed it to Linus yet though.
> 
>   Jesse> The fix is a simple change of NR_MEMBLKS to NR_NODE_MEMBLKS.
> 
>   Jesse> Jesse
> 
>   Jesse> On Fri, Feb 13, 2004 at 01:33:36PM -0800, David Mosberger
>   Jesse> wrote:
>   >> According to this page:
>   >> 
>   >> http://www.gelato.unsw.edu.au/kerncomp/
>   >> 
>   >> Generic kernel builds are still failing, due to some NUMA cruft.
>   >> I thought this was supposed to be fixed already.  Can someone who
>   >> cares about NUMA investigate?
>   >> 
>   >> -d-avid
>   >> -
>   >> To unsubscribe from this list: send the line "unsubscribe
>   >> linux-ia64" in the body of a message to majordomo@vger.kernel.org
>   >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GENERIC build failure

[Jesse Barnes]

On Fri, Feb 13, 2004 at 02:48:42PM -0800, Andrew Morton wrote:
> 
> I dropped the patch because it's fixed in Len's tree.
> 
> If someone can send me a tested standalone patch then sure.

Here you go.

Jesse


=== drivers/acpi/numa.c 1.7 vs edited ==--- 1.7/drivers/acpi/numa.c	Tue Jan 13 01:52:03 2004
+++ edited/drivers/acpi/numa.c	Wed Feb 11 17:31:34 2004
@@ -172,7 +172,7 @@
 					       NR_CPUS);
 		result = acpi_table_parse_srat(ACPI_SRAT_MEMORY_AFFINITY,
 					       acpi_parse_memory_affinity,
-					       NR_MEMBLKS);
+					       NR_NODE_MEMBLKS);
 	} else {
 		/* FIXME */
 		printk("Warning: acpi_table_parse(ACPI_SRAT) returned %d!\n",result);