On Fri, May 16, 2008 at 03:40:28PM -0700, Luck, Tony wrote:
> > A recent ACPI change (commit 5dc90c0b2d4bd0127624bab67cec159b2c6c4daf)
>
> -ENOSUCHCOMMIT ... well I can't see it in Linus' tree.
Sorry, I should have added more information.
It is in Andrew's tree (2.6.26-rc2-mm1). It has yet to make it to Linus' tree.
http://lkml.org/lkml/2008/5/14/366
The patch name is acpi-acpi_numa_init-build-fix
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.26-rc2/2.6.26-rc2-mm1/patch-list
git bisect found:
------------------------------------------------------------------------------------
5dc90c0b2d4bd0127624bab67cec159b2c6c4daf is first bad commit
commit 5dc90c0b2d4bd0127624bab67cec159b2c6c4daf
Author: Ingo Molnar <mingo@xxxxxxx>
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@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
:040000 040000 65397f028a8bc082be2bde667554c9115e88064b 58d35b65618fafdcbb449dd114e0381df467431d M drivers
------------------------------------------------------------------------------------
The inadvertent breakage is the patch puts #ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
around acpi_parse_memory_affinity() and acpi_table_parse_srat(), but Altix
needs to parse the SRAT. The result is that Altix dies early in boot in the
ACPI code.
The fix defines CONFIG_HAVE_ARCH_PARSE_SRAT in ia64 config and
prevents the parsing routines from being defined as stubs if
NR_NODE_MEMBLKS is defined.
Since the problem effects Altix, I sent the fix to linux-ia64. Would it
have been better to send the fix directly to lkml & Andrew?
This patch fixes the problem
------------------------------------------------------------------------------------
A recent ACPI change (commit 5dc90c0b2d4bd0127624bab67cec159b2c6c4daf)
inadvertently broke Altix boot. This patch allow Altix to boot.
Signed-off-by: Russ Anderson <rja@xxxxxxx>
Acked-by: Ingo Molnar <mingo@xxxxxxx>
---
arch/ia64/Kconfig | 4 ++++
include/linux/acpi.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
Index: 2.6.26-rc2/arch/ia64/Kconfig
===================================================================
--- 2.6.26-rc2.orig/arch/ia64/Kconfig 2008-05-16 09:36:37.285558037 -0500
+++ 2.6.26-rc2/arch/ia64/Kconfig 2008-05-16 09:37:39.149204580 -0500
@@ -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
Index: 2.6.26-rc2/include/linux/acpi.h
===================================================================
--- 2.6.26-rc2.orig/include/linux/acpi.h 2008-05-16 09:37:12.989971159 -0500
+++ 2.6.26-rc2/include/linux/acpi.h 2008-05-16 09:50:17.082906375 -0500
@@ -93,7 +93,7 @@ int acpi_parse_mcfg (struct acpi_table_h
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)
------------------------------------------------------------------------------------
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@xxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|