[PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be lifted.

The following two patches remove the restrictions on pagetable layout and
architecture type when setting NUMA on x86. This is aimed at improving
the testing coverage of NUMA code paths by allowing it to be set in more
situations. The dependency on CONFIG_ACPI is left due to possible SRAT
parsing (although this could also be lifted) and on EXPERIMENTAL as the
testing coverage for NUMA on x86 is so weak. The one potential gotcha is
that a definition of NR_NODE_MEMBLKS is moved to an arch-specific file. From
what I can see, this value was expected to be defined on a per-arch basis
and the definition in include/linux/acpi.h was an anomaly.

The patches in combination with the boot-numa-x86 fix have been boot-tested
on a bog-standard laptop with 512MB RAM, QEMU-i386 with 1324MB in a variety
of different configuarations and a NUMA-Q with its standard .config.

[1] For others watching, this fix was considered controversial as a
    potentially better solution existed as discussed in
    http://lkml.org/lkml/2007/8/24/220. However, this better alternative was
    never investigated properly and booting NUMA remained broken. The merged
    fix is a variation and while it does waste memory, it is considered better
    than crashing. Wider testing coverage may help motivate fixing this paths.
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

[PATCH 1/2] Do not require CONFIG_HIGHMEM64G to set CONFIG_NUMA on x86

[Mel Gorman]

There is nothing inherent in HIGHMEM64G required for CONFIG_NUMA to work. It
just limits potential testing coverage so remove the limitation.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---

 arch/x86/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-fix-numa-boot/arch/x86/Kconfig linux-2.6.24-rc8-005_non64GB/arch/x86/Kconfig
--- linux-2.6.24-rc8-fix-numa-boot/arch/x86/Kconfig	2008-01-16 04:22:48.000000000 +0000
+++ linux-2.6.24-rc8-005_non64GB/arch/x86/Kconfig	2008-01-17 18:22:26.000000000 +0000
@@ -817,7 +817,7 @@ config X86_PAE
 config NUMA
 	bool "Numa Memory Allocation and Scheduler Support (EXPERIMENTAL)"
 	depends on SMP
-	depends on X86_64 || (X86_32 && HIGHMEM64G && (X86_NUMAQ || (X86_SUMMIT || X86_GENERICARCH) && ACPI) && EXPERIMENTAL)
+	depends on X86_64 || (X86_32 && (X86_NUMAQ || (X86_SUMMIT || X86_GENERICARCH) && ACPI) && EXPERIMENTAL)
 	default n if X86_PC
 	default y if (X86_NUMAQ || X86_SUMMIT)
 	help

Re: [PATCH 1/2] Do not require CONFIG_HIGHMEM64G to set CONFIG_NUMA on x86

[Ingo Molnar]

* Mel Gorman <mel@csn.ul.ie> wrote:

> There is nothing inherent in HIGHMEM64G required for CONFIG_NUMA to 
> work. It just limits potential testing coverage so remove the 
> limitation.

thanks Mel, applied. Great change - this will trigger NUMA related build 
(and boot) failures must faster in randconfig testing.

	Ingo

[PATCH 2/2] Allow any x86 sub-architecture type to set CONFIG_NUMA

[Mel Gorman]

While there are a limited number of x86 sub-architecture types that can
really support NUMA, there is nothing stopping other machines booting that
type of kernel. The fact that X86_GENERICARCH can set NUMA currently is an
indicator of that. This restriction only limits potential testing coverage.
This patch allows any sub-architecture to set CONFIG_NUMA if they wish.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---

 arch/x86/Kconfig          |    2 +-
 include/asm-x86/acpi_32.h |    1 +
 include/linux/acpi.h      |    1 -
 3 files changed, 2 insertions(+), 2 deletions(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-005_non64GB/arch/x86/Kconfig linux-2.6.24-rc8-010_any32bit_x86/arch/x86/Kconfig
--- linux-2.6.24-rc8-005_non64GB/arch/x86/Kconfig	2008-01-17 18:22:26.000000000 +0000
+++ linux-2.6.24-rc8-010_any32bit_x86/arch/x86/Kconfig	2008-01-17 18:22:37.000000000 +0000
@@ -817,7 +817,7 @@ config X86_PAE
 config NUMA
 	bool "Numa Memory Allocation and Scheduler Support (EXPERIMENTAL)"
 	depends on SMP
-	depends on X86_64 || (X86_32 && (X86_NUMAQ || (X86_SUMMIT || X86_GENERICARCH) && ACPI) && EXPERIMENTAL)
+	depends on X86_64 || (X86_32 && ACPI && EXPERIMENTAL)
 	default n if X86_PC
 	default y if (X86_NUMAQ || X86_SUMMIT)
 	help
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-005_non64GB/include/asm-x86/acpi_32.h linux-2.6.24-rc8-010_any32bit_x86/include/asm-x86/acpi_32.h
--- linux-2.6.24-rc8-005_non64GB/include/asm-x86/acpi_32.h	2008-01-16 04:22:48.000000000 +0000
+++ linux-2.6.24-rc8-010_any32bit_x86/include/asm-x86/acpi_32.h	2008-01-17 18:22:37.000000000 +0000
@@ -84,6 +84,7 @@ int __acpi_release_global_lock(unsigned 
 extern void early_quirks(void);
 
 #ifdef CONFIG_ACPI
+#define NR_NODE_MEMBLKS MAX_NUMNODES
 extern int acpi_lapic;
 extern int acpi_ioapic;
 extern int acpi_noirq;
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-005_non64GB/include/linux/acpi.h linux-2.6.24-rc8-010_any32bit_x86/include/linux/acpi.h
--- linux-2.6.24-rc8-005_non64GB/include/linux/acpi.h	2008-01-16 04:22:48.000000000 +0000
+++ linux-2.6.24-rc8-010_any32bit_x86/include/linux/acpi.h	2008-01-17 18:22:37.000000000 +0000
@@ -94,7 +94,6 @@ void acpi_table_print_madt_entry (struct
 
 /* the following four functions are architecture-dependent */
 #ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
-#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)
 #define acpi_numa_memory_affinity_init(ma) do {} while (0)

Re: [PATCH 2/2] Allow any x86 sub-architecture type to set CONFIG_NUMA

[Ingo Molnar]

* Mel Gorman <mel@csn.ul.ie> wrote:

> While there are a limited number of x86 sub-architecture types that 
> can really support NUMA, there is nothing stopping other machines 
> booting that type of kernel. The fact that X86_GENERICARCH can set 
> NUMA currently is an indicator of that. This restriction only limits 
> potential testing coverage. This patch allows any sub-architecture to 
> set CONFIG_NUMA if they wish.

thanks, applied.

	Ingo

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Andi Kleen]

Mel Gorman <mel@csn.ul.ie> writes:

> A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> at the restrictions on setting NUMA on x86 to see if they could be lifted.

The problem with i386 CONFIG_NUMA previously was not that it didn't
boot on normal non NUMA systems, but that it didn't boot on very
common NUMA systems: Opterons.  Have you tested if that is fixed now?

-Andi

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (19/01/08 07:35), Andi Kleen didst pronounce:
> Mel Gorman <mel@csn.ul.ie> writes:
> 
> > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > at the restrictions on setting NUMA on x86 to see if they could be lifted.
> 
> The problem with i386 CONFIG_NUMA previously was not that it didn't
> boot on normal non NUMA systems, but that it didn't boot on very
> common NUMA systems: Opterons.  Have you tested if that is fixed now?
> 

No, I hadn't but I can imagine how such an odd situation would occur for
distribution kernels even if it's a bit of a waste of hardware. I tested
this situation on a 4-node NUMA Opteron box. It didn't work very well based
on a few problems.

- alloc_remap() and SPARSEMEM on HIGHMEM4G explodes [1]
- Without SRAT, there is a build failure 
- Enabling SRAT requires BOOT_IOREMAP and it explodes early in boot

I have one fix for items 1 and 2 with the patch below. It probably should
be split in two but lets see if we want to pursue alternative fixes to this
problem first. In particular, this patch stops SPARSEMEM using alloc_remap()
because not enough memory is set aside. An alternative solution may be to
reserve more for alloc_remap() when SPARSEMEM is in use. 

With the patch applied, an x86-64 capable NUMA Opteron box will boot a 32
bit NUMA enabled kernel with DISCONTIGMEM or SPARSEMEM. Due to the lack of
SRAT parsing, there is only node 0 of course.

Based on this, I have no doubt there is going to be a series of broken boots
while stuff like this gets rattled out. For the moment, NUMA on x86
32-bit should remain CONFIG_EXPERIMENTAL.

[1] It happens to work on HIGHMEM64G and I'm guessing it's because
    alloc_remap() never succeeds although I did not verify that guess. I
    suspect there are a few more HIGHMEM4G oddities to rattle out and I
    didn't even try NOHIGHMEM.

=====

Subject: Fix boot-problems related to x86 32 bit with CONFIG_NUMA

The DISCONTIG memory model on x86 32 bit uses a remap allocator early
in boot. The objective is that portions of every node are mapped in to
the kernel virtual area (KVA) in place of ZONE_NORMAL so that node-local
allocations can be made for pgdat and mem_map structures.

With SPARSEMEM, the amount that is set aside is insufficient for all the
mem_maps to be allocated. During the boot process, it falls back to using
the bootmem allocator. This breaks assumptions that SPARSEMEM makes about
the layout of the mem_map in memory and results in a VM_BUG_ON triggering
due to pfn_to_page() returning garbage values.

This patch only enables the remap allocator for use with DISCONTIG.

Without SRAT support, a compile-error occurs because ACPI table parsing
functions are only available in x86-64. This patch also adds no-op stubs
and prints a warning message. What likely needs to be done is sharing
the table parsing functions between 32 and 64 bit if they are
compatible.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>

---

 arch/x86/mm/discontig_32.c |   93 +++++++++++++++++++++++++++++++++++++--------
 1 file changed, 78 insertions(+), 15 deletions(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-010_any32bit_x86/arch/x86/mm/discontig_32.c linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c
--- linux-2.6.24-rc8-010_any32bit_x86/arch/x86/mm/discontig_32.c	2008-01-17 15:40:21.000000000 +0000
+++ linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c	2008-01-19 15:50:47.000000000 +0000
@@ -32,6 +32,7 @@
 #include <linux/kexec.h>
 #include <linux/pfn.h>
 #include <linux/swap.h>
+#include <linux/acpi.h>
 
 #include <asm/e820.h>
 #include <asm/setup.h>
@@ -103,14 +104,10 @@ extern unsigned long highend_pfn, highst
 
 #define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
 
-static unsigned long node_remap_start_pfn[MAX_NUMNODES];
 unsigned long node_remap_size[MAX_NUMNODES];
-static unsigned long node_remap_offset[MAX_NUMNODES];
 static void *node_remap_start_vaddr[MAX_NUMNODES];
 void set_pmd_pfn(unsigned long vaddr, unsigned long pfn, pgprot_t flags);
 
-static void *node_remap_end_vaddr[MAX_NUMNODES];
-static void *node_remap_alloc_vaddr[MAX_NUMNODES];
 static unsigned long kva_start_pfn;
 static unsigned long kva_pages;
 /*
@@ -167,6 +164,22 @@ static void __init allocate_pgdat(int ni
 	}
 }
 
+#ifdef CONFIG_DISCONTIGMEM
+/*
+ * In the discontig memory model, a portion of the kernel virtual area (KVA)
+ * is reserved and portions of nodes are mapped using it. This is to allow
+ * node-local memory to be allocated for structures that would normally require
+ * ZONE_NORMAL. The memory is allocated with alloc_remap() and callers
+ * should be prepared to allocate from the bootmem allocator instead. This KVA
+ * mechanism is incompatible with SPARSEMEM as it makes assumptions about the
+ * layout of memory that are broken if alloc_remap() succeeds for some of the
+ * map and fails for others
+ */
+static unsigned long node_remap_start_pfn[MAX_NUMNODES];
+static void *node_remap_end_vaddr[MAX_NUMNODES];
+static void *node_remap_alloc_vaddr[MAX_NUMNODES];
+static unsigned long node_remap_offset[MAX_NUMNODES];
+
 void *alloc_remap(int nid, unsigned long size)
 {
 	void *allocation = node_remap_alloc_vaddr[nid];
@@ -263,6 +276,40 @@ static unsigned long calculate_numa_rema
 	return reserve_pages;
 }
 
+static void init_remap_allocator(int nid)
+{
+	node_remap_start_vaddr[nid] = pfn_to_kaddr(
+			kva_start_pfn + node_remap_offset[nid]);
+	node_remap_end_vaddr[nid] = node_remap_start_vaddr[nid] +
+		(node_remap_size[nid] * PAGE_SIZE);
+	node_remap_alloc_vaddr[nid] = node_remap_start_vaddr[nid] +
+		ALIGN(sizeof(pg_data_t), PAGE_SIZE);
+
+	printk ("node %d will remap to vaddr %08lx - %08lx\n", nid,
+		(ulong) node_remap_start_vaddr[nid],
+		(ulong) pfn_to_kaddr(highstart_pfn
+		   + node_remap_offset[nid] + node_remap_size[nid]));
+}
+#else
+void *alloc_remap(int nid, unsigned long size)
+{
+	return NULL;
+}
+
+static unsigned long calculate_numa_remap_pages(void)
+{
+	return 0;
+}
+
+static void init_remap_allocator(int nid)
+{
+}
+
+void __init remap_numa_kva(void)
+{
+}
+#endif /* CONFIG_DISCONTIGMEM */
+
 extern void setup_bootmem_allocator(void);
 unsigned long __init setup_memory(void)
 {
@@ -326,19 +373,9 @@ unsigned long __init setup_memory(void)
 	printk("Low memory ends at vaddr %08lx\n",
 			(ulong) pfn_to_kaddr(max_low_pfn));
 	for_each_online_node(nid) {
-		node_remap_start_vaddr[nid] = pfn_to_kaddr(
-				kva_start_pfn + node_remap_offset[nid]);
-		/* Init the node remap allocator */
-		node_remap_end_vaddr[nid] = node_remap_start_vaddr[nid] +
-			(node_remap_size[nid] * PAGE_SIZE);
-		node_remap_alloc_vaddr[nid] = node_remap_start_vaddr[nid] +
-			ALIGN(sizeof(pg_data_t), PAGE_SIZE);
+		init_remap_allocator(nid);
 
 		allocate_pgdat(nid);
-		printk ("node %d will remap to vaddr %08lx - %08lx\n", nid,
-			(ulong) node_remap_start_vaddr[nid],
-			(ulong) pfn_to_kaddr(highstart_pfn
-			   + node_remap_offset[nid] + node_remap_size[nid]));
 	}
 	printk("High memory starts at vaddr %08lx\n",
 			(ulong) pfn_to_kaddr(highstart_pfn));
@@ -439,3 +476,29 @@ int memory_add_physaddr_to_nid(u64 addr)
 
 EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
 #endif
+
+#ifndef CONFIG_HAVE_ARCH_PARSE_SRAT
+/*
+ * XXX FIXME: Make SLIT table parsing available to 32-bit NUMA
+ *
+ * These stub functions are needed to compile 32-bit NUMA when SRAT is
+ * not set. There are functions in srat_64.c for parsing this table
+ * and it may be possible to make them common functions.
+ */
+static inline void acpi_numa_slit_init (struct acpi_table_slit *slit)
+{
+	printk(KERN_INFO "ACPI: No support for parsing SLIT table\n");
+}
+
+void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa)
+{
+}
+
+void acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma)
+{
+}
+
+void acpi_numa_arch_fixup(void)
+{
+}
+#endif /* CONFIG_HAVE_ARCH_PARSE_SRAT */

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Ingo Molnar]

* Mel Gorman <mel@csn.ul.ie> wrote:

> [...] I tested this situation on a 4-node NUMA Opteron box. It didn't 
> work very well based on a few problems.
> 
> - alloc_remap() and SPARSEMEM on HIGHMEM4G explodes [1]
> - Without SRAT, there is a build failure 
> - Enabling SRAT requires BOOT_IOREMAP and it explodes early in boot
> 
> I have one fix for items 1 and 2 with the patch below. It probably 
> should be split in two but lets see if we want to pursue alternative 
> fixes to this problem first. In particular, this patch stops SPARSEMEM 
> using alloc_remap() because not enough memory is set aside. An 
> alternative solution may be to reserve more for alloc_remap() when 
> SPARSEMEM is in use.
> 
> With the patch applied, an x86-64 capable NUMA Opteron box will boot a 
> 32 bit NUMA enabled kernel with DISCONTIGMEM or SPARSEMEM. Due to the 
> lack of SRAT parsing, there is only node 0 of course.
> 
> Based on this, I have no doubt there is going to be a series of broken 
> boots while stuff like this gets rattled out. For the moment, NUMA on 
> x86 32-bit should remain CONFIG_EXPERIMENTAL.

thanks, applied.

	Ingo

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (22/01/08 13:14), Ingo Molnar didst pronounce:
> 
> * Mel Gorman <mel@csn.ul.ie> wrote:
> 
> > [...] I tested this situation on a 4-node NUMA Opteron box. It didn't 
> > work very well based on a few problems.
> > 
> > - alloc_remap() and SPARSEMEM on HIGHMEM4G explodes [1]
> > - Without SRAT, there is a build failure 
> > - Enabling SRAT requires BOOT_IOREMAP and it explodes early in boot
> > 
> > I have one fix for items 1 and 2 with the patch below. It probably 
> > should be split in two but lets see if we want to pursue alternative 
> > fixes to this problem first. In particular, this patch stops SPARSEMEM 
> > using alloc_remap() because not enough memory is set aside. An 
> > alternative solution may be to reserve more for alloc_remap() when 
> > SPARSEMEM is in use.
> > 
> > With the patch applied, an x86-64 capable NUMA Opteron box will boot a 
> > 32 bit NUMA enabled kernel with DISCONTIGMEM or SPARSEMEM. Due to the 
> > lack of SRAT parsing, there is only node 0 of course.
> > 
> > Based on this, I have no doubt there is going to be a series of broken 
> > boots while stuff like this gets rattled out. For the moment, NUMA on 
> > x86 32-bit should remain CONFIG_EXPERIMENTAL.
> 
> thanks, applied.
> 

Sorry, there was a screwup on my behalf. The version I sent still had a
stray static inline in it.  It will fail to compile without this.

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c linux-2.6.24-rc8-015_remap_discontigmem-fix/arch/x86/mm/discontig_32.c
--- linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c	2008-01-22 12:27:52.000000000 +0000
+++ linux-2.6.24-rc8-015_remap_discontigmem-fix/arch/x86/mm/discontig_32.c	2008-01-22 12:28:39.000000000 +0000
@@ -485,7 +485,7 @@ EXPORT_SYMBOL_GPL(memory_add_physaddr_to
  * not set. There are functions in srat_64.c for parsing this table
  * and it may be possible to make them common functions.
  */
-static inline void acpi_numa_slit_init (struct acpi_table_slit *slit)
+void acpi_numa_slit_init (struct acpi_table_slit *slit)
 {
 	printk(KERN_INFO "ACPI: No support for parsing SLIT table\n");
 }

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Ingo Molnar]

* Mel Gorman <mel@csn.ul.ie> wrote:

> Sorry, there was a screwup on my behalf. The version I sent still had 
> a stray static inline in it.  It will fail to compile without this.

ok, picked up that fix too, thanks.

	Ingo

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Andi Kleen]

> Without SRAT support, a compile-error occurs because ACPI table parsing
> functions are only available in x86-64. This patch also adds no-op stubs
> and prints a warning message. What likely needs to be done is sharing
> the table parsing functions between 32 and 64 bit if they are
> compatible.

I'm a little confused by your patch.

i386 already has srat parsing code (just written in a horrible hackish way); 
but it exists arch/x86/kernel/srat_32.c

That one tended to explode on Opteron, but apparently worked on some 
Summit boxes.

You're saying you want to remove that code and replace it based on something
based on the drivers/acpi/numa.c parsing code? While that's in theory
a worthy goal it will not actually help all that much because numa.c only
does some high level parsing, but nothing of the actual low level work
of setting things up.

-Andi

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (22/01/08 14:33), Andi Kleen didst pronounce:
> 
> > Without SRAT support, a compile-error occurs because ACPI table parsing
> > functions are only available in x86-64. This patch also adds no-op stubs
> > and prints a warning message. What likely needs to be done is sharing
> > the table parsing functions between 32 and 64 bit if they are
> > compatible.
> 
> I'm a little confused by your patch.
> 
> i386 already has srat parsing code (just written in a horrible hackish way); 
> but it exists arch/x86/kernel/srat_32.c
> 

Yes, I spotted that. Enabling it required a Kconfig change or two and
enabling BOOT_IOREMAP. It then crashes early in boot on a call to strlen()
so I went with the stubs and SRAT disabled for the moment.

> That one tended to explode on Opteron, but apparently worked on some 
> Summit boxes.
> 
> You're saying you want to remove that code and replace it based on something
> based on the drivers/acpi/numa.c parsing code?

I made the assumption that they were basically the same. That is obviously
wrong from what you say below.

> While that's in theory
> a worthy goal it will not actually help all that much because numa.c only
> does some high level parsing, but nothing of the actual low level work
> of setting things up.
> 

Ok, understood. When I next revisit this, I'll look at making ACPI_SRAT
and BOOT_IOREMAP work on normal machines and see what happens. Thanks.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Andi Kleen]

> > i386 already has srat parsing code (just written in a horrible hackish
> > way); but it exists arch/x86/kernel/srat_32.c
>
> Yes, I spotted that. Enabling it required a Kconfig change 

does it? I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
already used that. At least that was the case when I last looked. If that
has changed it must have bitrotted recently.

> or two and 
> enabling BOOT_IOREMAP. It then crashes early in boot on a call to strlen()
> so I went with the stubs and SRAT disabled for the moment.

Crashed on a Opteron box? That was always the case

If it crashed on a (older) Summit then it likely bitrotted, because that 
worked at some point. The code was originally written by Pat G. for Summit1
and I believe was at least used by some people (no distributions) for S2,
possible 3 too.

> Ok, understood. When I next revisit this, I'll look at making ACPI_SRAT
> and BOOT_IOREMAP work on normal machines and see what happens. Thanks.

Again the problem shouldn't be normal machines, but non Summit NUMA systems.

-Andi

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (23/01/08 11:45), Andi Kleen didst pronounce:
> 
> > > i386 already has srat parsing code (just written in a horrible hackish
> > > way); but it exists arch/x86/kernel/srat_32.c
> >
> > Yes, I spotted that. Enabling it required a Kconfig change 
> 
> does it?

hmm, just a removal of (X86_SUMMIT || X86_GENERICARCH). When I was testing
this I was probably using a PC-compatible configuration as that is what I
was enabling at the time. It's a similar restriction for BOOT_IOREMAP.

> I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
> already used that.

Presumably a GENERICARCH configuration

> At least that was the case when I last looked. If that
> has changed it must have bitrotted recently.
> 

I don't think it has bit-rotted. I was just not using a GENERICARCH
configuration.

> > or two and 
> > enabling BOOT_IOREMAP. It then crashes early in boot on a call to strlen()
> > so I went with the stubs and SRAT disabled for the moment.
> 
> Crashed on a Opteron box? That was always the case
> 

Yeah, elm3b6 from test.kernel.org is an Opteron-based NUMA machine. Oddly
it's good to know that the nature of the crash has not changed.

> If it crashed on a (older) Summit then it likely bitrotted, because that 
> worked at some point. The code was originally written by Pat G. for Summit1
> and I believe was at least used by some people (no distributions) for S2,
> possible 3 too.
> 

Unfortunately, I don't have access to a Summit box so I cannot verify.

> > Ok, understood. When I next revisit this, I'll look at making ACPI_SRAT
> > and BOOT_IOREMAP work on normal machines and see what happens. Thanks.
> 
> Again the problem shouldn't be normal machines, but non Summit NUMA systems.
> 

Grand. I'll get back to this soon and see what can be done.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Andi Kleen]

> > I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
> > already used that.
>
> Presumably a GENERICARCH configuration

GENERICARCH includes SUMMIT so yes.

> > At least that was the case when I last looked. If that
> > has changed it must have bitrotted recently.
>
> I don't think it has bit-rotted. I was just not using a GENERICARCH
> configuration.

And no SUMMIT either?  Ok you already answered that later.

-Andi

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 II

[Andi Kleen]

Anyways from your earlier comments it sounds like you're trying to add SRAT 
parsing to CONFIG_NUMAQ. Since that's redundant with the old implementation
it doesn't sound like a very useful thing to do.

But the patch is applied already i think. Well I'm sure it passed 
checkpatch.pl at least.

-Andi

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 II

[Mel Gorman]

On (23/01/08 12:15), Andi Kleen didst pronounce:
> 
> Anyways from your earlier comments it sounds like you're trying to add SRAT 
> parsing to CONFIG_NUMAQ. Since that's redundant with the old implementation
> it doesn't sound like a very useful thing to do.
> 

No, that would not be useful at all as it's redundant as you point out. The
only reason to add it is if the Opteron box can figure out the CPU-to-node
affinity. Right now everything gets dumped into node 0 where as x86_64
can figure it out properly.

> But the patch is applied already i think. Well I'm sure it passed 
> checkpatch.pl at least.
> 

:| The patches applied so far are about increasing test coverage, not SRAT
messing. While there are still breakages for some boxen, more configurations
should work on more machines than previously. Those using non-NUMA .configs
should not notice the difference.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 II

[Andi Kleen]

On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
> On (23/01/08 12:15), Andi Kleen didst pronounce:
> > Anyways from your earlier comments it sounds like you're trying to add
> > SRAT parsing to CONFIG_NUMAQ. Since that's redundant with the old
> > implementation it doesn't sound like a very useful thing to do.
>
> No, that would not be useful at all as it's redundant as you point out. The
> only reason to add it is if the Opteron box can figure out the CPU-to-node
> affinity. 

Assuming srat_32.c was fixed to not crash on Opteron it would likely
do that already without further changes.

> :| The patches applied so far are about increasing test coverage, not SRAT
> messing. 

Test coverage of the NUMAQ kernel?

If you wanted to increase test coverage of 32bit NUMA kernels the right
strategy would be to fix srat_32.

-Andi

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 II

[Mel Gorman]

On (23/01/08 14:48), Andi Kleen didst pronounce:
> On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
> > On (23/01/08 12:15), Andi Kleen didst pronounce:
> > > Anyways from your earlier comments it sounds like you're trying to add
> > > SRAT parsing to CONFIG_NUMAQ. Since that's redundant with the old
> > > implementation it doesn't sound like a very useful thing to do.
> >
> > No, that would not be useful at all as it's redundant as you point out. The
> > only reason to add it is if the Opteron box can figure out the CPU-to-node
> > affinity. 
> 
> Assuming srat_32.c was fixed to not crash on Opteron it would likely
> do that already without further changes.
> 

Understood.

> > :| The patches applied so far are about increasing test coverage, not SRAT
> > messing. 
> 
> Test coverage of the NUMAQ kernel?
> 

NUMA in general. I don't really care about NUMAQ as such except that it
continues to shake out the occasional bug that can be difficult to reproduce
elsewhere.

> If you wanted to increase test coverage of 32bit NUMA kernels the right
> strategy would be to fix srat_32.
> 

I will try and do that then instead of trying to merge the SRAT parsers.
Based on this thread, my understanding is that an attempted merge would only
open up a can of hurt, probably causing regressions in the process.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[KOSAKI Motohiro]

Hi 

> A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> at the restrictions on setting NUMA on x86 to see if they could be lifted.

Interesting!

I will test tomorrow.
I think this patch become easy to the porting of fakenuma.

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (21/01/08 09:38), KOSAKI Motohiro didst pronounce:
> Hi 
> 
> > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > at the restrictions on setting NUMA on x86 to see if they could be lifted.
> 
> Interesting!
> 
> I will test tomorrow.

Thanks.

> I think this patch become easy to the porting of fakenuma.
> 

It would be great if that was available, particularly if it could fake
memoryless nodes as that is a place where we've found a few
difficult-to-reproduce bugs.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Ingo Molnar]

* Mel Gorman <mel@csn.ul.ie> wrote:

> > I think this patch become easy to the porting of fakenuma.
> 
> It would be great if that was available, particularly if it could fake 
> memoryless nodes as that is a place where we've found a few 
> difficult-to-reproduce bugs.

yeah. Your previous patch (see below) had build problems - are those 
resolved meanwhile?

	Ingo

----------->
Subject: x86: allow any x86 sub-architecture type to set CONFIG_NUMA
From: Mel Gorman <mel@csn.ul.ie>

While there are a limited number of x86 sub-architecture types that can
really support NUMA, there is nothing stopping other machines booting that
type of kernel. The fact that X86_GENERICARCH can set NUMA currently is an
indicator of that. This restriction only limits potential testing coverage.
This patch allows any sub-architecture to set CONFIG_NUMA if they wish.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---

 arch/x86/Kconfig       |    2 +-
 include/asm-x86/acpi.h |    1 +
 include/linux/acpi.h   |    1 -
 3 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-x86.q/arch/x86/Kconfig
===================================================================
--- linux-x86.q.orig/arch/x86/Kconfig
+++ linux-x86.q/arch/x86/Kconfig
@@ -816,7 +816,7 @@ config X86_PAE
 config NUMA
 	bool "Numa Memory Allocation and Scheduler Support (EXPERIMENTAL)"
 	depends on SMP
-	depends on X86_64 || (X86_32 && (X86_NUMAQ || (X86_SUMMIT || X86_GENERICARCH) && ACPI) && EXPERIMENTAL)
+	depends on X86_64 || (X86_32 && ACPI && EXPERIMENTAL)
 	default n if X86_PC
 	default y if (X86_NUMAQ || X86_SUMMIT)
 	help
Index: linux-x86.q/include/asm-x86/acpi.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/acpi.h
+++ linux-x86.q/include/asm-x86/acpi.h
@@ -79,6 +79,7 @@ int __acpi_release_global_lock(unsigned 
 	    :"0"(n_hi), "1"(n_lo))
 
 #ifdef CONFIG_ACPI
+#define NR_NODE_MEMBLKS MAX_NUMNODES
 extern int acpi_lapic;
 extern int acpi_ioapic;
 extern int acpi_noirq;
Index: linux-x86.q/include/linux/acpi.h
===================================================================
--- linux-x86.q.orig/include/linux/acpi.h
+++ linux-x86.q/include/linux/acpi.h
@@ -95,7 +95,6 @@ void acpi_table_print_madt_entry (struct
 
 /* the following four functions are architecture-dependent */
 #ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
-#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)
 #define acpi_numa_memory_affinity_init(ma) do {} while (0)

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (21/01/08 15:49), Ingo Molnar didst pronounce:
> 
> * Mel Gorman <mel@csn.ul.ie> wrote:
> 
> > > I think this patch become easy to the porting of fakenuma.
> > 
> > It would be great if that was available, particularly if it could fake 
> > memoryless nodes as that is a place where we've found a few 
> > difficult-to-reproduce bugs.
> 
> yeah. Your previous patch (see below) had build problems - are those 
> resolved meanwhile?
> 

Odd, I couldn't reproduce it Friday and could today. Clearly I was not
firing on all cylinders. The problem was because NUMA && FLATMEM are
incompatible. Thanks for nudging a second time.

However in the patch below addressing the problem below, would it make more
sense to replace X86_PC with !NUMA instead of having X86_PC && !NUMA?

===

Subject: Do not allow FLATMEM && NUMA to be set on x86 at the same time

The FLATMEM memory model references a global mem_map and max_mapnr. This
is incompatible with how memory models used for NUMA view the world.
Builds fail if FLATMEM && NUMA are set on x86. This patch forbids that
combination of config items. This is consistent with x86_64
enforcements.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
--- 
 arch/x86/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-020_init_kmem3lists_nodes/arch/x86/Kconfig linux-2.6.24-rc8-025_memmap_reffix/arch/x86/Kconfig
--- linux-2.6.24-rc8-020_init_kmem3lists_nodes/arch/x86/Kconfig	2008-01-19 15:26:00.000000000 +0000
+++ linux-2.6.24-rc8-025_memmap_reffix/arch/x86/Kconfig	2008-01-21 15:51:03.000000000 +0000
@@ -891,7 +891,7 @@ config HAVE_ARCH_ALLOC_REMAP
 
 config ARCH_FLATMEM_ENABLE
 	def_bool y
-	depends on (X86_32 && ARCH_SELECT_MEMORY_MODEL && X86_PC) || (X86_64 && !NUMA)
+	depends on (X86_32 && ARCH_SELECT_MEMORY_MODEL && X86_PC && !NUMA) || (X86_64 && !NUMA)
 
 config ARCH_DISCONTIGMEM_ENABLE
 	def_bool y
-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[KOSAKI Motohiro]

Hi mel

> Hi 
> 
> > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > at the restrictions on setting NUMA on x86 to see if they could be lifted.
> 
> Interesting!
> 
> I will test tomorrow.

Hmm...
It doesn't works on my machine.

panic at booting at __free_pages_ok() with blow call trace.

[<hex number>] free_all_bootmem_core
[<hex number>] mem_init
[<hex number>] alloc_large_system_hash
[<hex number>] inode_init_early
[<hex number>] start_kernel
[<hex number>] unknown_bootoption

my machine spec
	CPU:   Pentium4 with HT
	MEM:   512M

I will try more investigate.
but I have no time for a while, sorry ;-)


BTW:
when config sparse mem turn on instead discontig mem.
panic at booting at get_pageblock_flags_group() with below call stack.

free_initrd
	free_init_pages
		free_hot_cold_page



- kosaki

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (23/01/08 11:04), KOSAKI Motohiro didst pronounce:
> Hi mel
> 
> > Hi 
> > 
> > > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > > at the restrictions on setting NUMA on x86 to see if they could be lifted.
> > 
> > Interesting!
> > 
> > I will test tomorrow.
> 
> Hmm...
> It doesn't works on my machine.
> 
> panic at booting at __free_pages_ok() with blow call trace.
> 
> [<hex number>] free_all_bootmem_core
> [<hex number>] mem_init
> [<hex number>] alloc_large_system_hash
> [<hex number>] inode_init_early
> [<hex number>] start_kernel
> [<hex number>] unknown_bootoption
> 
> my machine spec
> 	CPU:   Pentium4 with HT
> 	MEM:   512M
> 
> I will try more investigate.
> but I have no time for a while, sorry ;-)
> 
> 
> BTW:
> when config sparse mem turn on instead discontig mem.
> panic at booting at get_pageblock_flags_group() with below call stack.
> 
> free_initrd
> 	free_init_pages
> 		free_hot_cold_page
> 

To rule it out, can you also try with the patch below applied please? It
should only make a difference on sparsemem so if discontigmem is still
crashing, there is likely another problem. Assuming it crashes, please
post the full dmesg output with loglevel=8 on the command line. Thanks

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[KOSAKI Motohiro]

Hi

> To rule it out, can you also try with the patch below applied please? It
> should only make a difference on sparsemem so if discontigmem is still
> crashing, there is likely another problem. Assuming it crashes, 

Aaah, sorry.
I can't test again until next week.

I repost at that time...


> please
> post the full dmesg output with loglevel=8 on the command line. Thanks

You are right..
I omitted it at previous mail, sorry.

because piking up dmesg is very difficult when boot time crash. ;-)


- kosaki

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (23/01/08 11:04), KOSAKI Motohiro didst pronounce:
> Hi mel
> 
> > Hi 
> > 
> > > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > > at the restrictions on setting NUMA on x86 to see if they could be lifted.
> > 
> > Interesting!
> > 
> > I will test tomorrow.
> 
> Hmm...
> It doesn't works on my machine.
> 
> panic at booting at __free_pages_ok() with blow call trace.
> 
> [<hex number>] free_all_bootmem_core
> [<hex number>] mem_init
> [<hex number>] alloc_large_system_hash
> [<hex number>] inode_init_early
> [<hex number>] start_kernel
> [<hex number>] unknown_bootoption
> 
> my machine spec
> 	CPU:   Pentium4 with HT
> 	MEM:   512M
> 
> I will try more investigate.
> but I have no time for a while, sorry ;-)
> 
> 
> BTW:
> when config sparse mem turn on instead discontig mem.
> panic at booting at get_pageblock_flags_group() with below call stack.
> 
> free_initrd
> 	free_init_pages
> 		free_hot_cold_page
> 
> 

And the actual patch :/

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-010_any32bit_x86/arch/x86/mm/discontig_32.c linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c
--- linux-2.6.24-rc8-010_any32bit_x86/arch/x86/mm/discontig_32.c	2008-01-17 15:40:21.000000000 +0000
+++ linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c	2008-01-19 15:50:47.000000000 +0000
@@ -32,6 +32,7 @@
 #include <linux/kexec.h>
 #include <linux/pfn.h>
 #include <linux/swap.h>
+#include <linux/acpi.h>
 
 #include <asm/e820.h>
 #include <asm/setup.h>
@@ -103,14 +104,10 @@ extern unsigned long highend_pfn, highst
 
 #define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
 
-static unsigned long node_remap_start_pfn[MAX_NUMNODES];
 unsigned long node_remap_size[MAX_NUMNODES];
-static unsigned long node_remap_offset[MAX_NUMNODES];
 static void *node_remap_start_vaddr[MAX_NUMNODES];
 void set_pmd_pfn(unsigned long vaddr, unsigned long pfn, pgprot_t flags);
 
-static void *node_remap_end_vaddr[MAX_NUMNODES];
-static void *node_remap_alloc_vaddr[MAX_NUMNODES];
 static unsigned long kva_start_pfn;
 static unsigned long kva_pages;
 /*
@@ -167,6 +164,22 @@ static void __init allocate_pgdat(int ni
 	}
 }
 
+#ifdef CONFIG_DISCONTIGMEM
+/*
+ * In the discontig memory model, a portion of the kernel virtual area (KVA)
+ * is reserved and portions of nodes are mapped using it. This is to allow
+ * node-local memory to be allocated for structures that would normally require
+ * ZONE_NORMAL. The memory is allocated with alloc_remap() and callers
+ * should be prepared to allocate from the bootmem allocator instead. This KVA
+ * mechanism is incompatible with SPARSEMEM as it makes assumptions about the
+ * layout of memory that are broken if alloc_remap() succeeds for some of the
+ * map and fails for others
+ */
+static unsigned long node_remap_start_pfn[MAX_NUMNODES];
+static void *node_remap_end_vaddr[MAX_NUMNODES];
+static void *node_remap_alloc_vaddr[MAX_NUMNODES];
+static unsigned long node_remap_offset[MAX_NUMNODES];
+
 void *alloc_remap(int nid, unsigned long size)
 {
 	void *allocation = node_remap_alloc_vaddr[nid];
@@ -263,6 +276,40 @@ static unsigned long calculate_numa_rema
 	return reserve_pages;
 }
 
+static void init_remap_allocator(int nid)
+{
+	node_remap_start_vaddr[nid] = pfn_to_kaddr(
+			kva_start_pfn + node_remap_offset[nid]);
+	node_remap_end_vaddr[nid] = node_remap_start_vaddr[nid] +
+		(node_remap_size[nid] * PAGE_SIZE);
+	node_remap_alloc_vaddr[nid] = node_remap_start_vaddr[nid] +
+		ALIGN(sizeof(pg_data_t), PAGE_SIZE);
+
+	printk ("node %d will remap to vaddr %08lx - %08lx\n", nid,
+		(ulong) node_remap_start_vaddr[nid],
+		(ulong) pfn_to_kaddr(highstart_pfn
+		   + node_remap_offset[nid] + node_remap_size[nid]));
+}
+#else
+void *alloc_remap(int nid, unsigned long size)
+{
+	return NULL;
+}
+
+static unsigned long calculate_numa_remap_pages(void)
+{
+	return 0;
+}
+
+static void init_remap_allocator(int nid)
+{
+}
+
+void __init remap_numa_kva(void)
+{
+}
+#endif /* CONFIG_DISCONTIGMEM */
+
 extern void setup_bootmem_allocator(void);
 unsigned long __init setup_memory(void)
 {
@@ -326,19 +373,9 @@ unsigned long __init setup_memory(void)
 	printk("Low memory ends at vaddr %08lx\n",
 			(ulong) pfn_to_kaddr(max_low_pfn));
 	for_each_online_node(nid) {
-		node_remap_start_vaddr[nid] = pfn_to_kaddr(
-				kva_start_pfn + node_remap_offset[nid]);
-		/* Init the node remap allocator */
-		node_remap_end_vaddr[nid] = node_remap_start_vaddr[nid] +
-			(node_remap_size[nid] * PAGE_SIZE);
-		node_remap_alloc_vaddr[nid] = node_remap_start_vaddr[nid] +
-			ALIGN(sizeof(pg_data_t), PAGE_SIZE);
+		init_remap_allocator(nid);
 
 		allocate_pgdat(nid);
-		printk ("node %d will remap to vaddr %08lx - %08lx\n", nid,
-			(ulong) node_remap_start_vaddr[nid],
-			(ulong) pfn_to_kaddr(highstart_pfn
-			   + node_remap_offset[nid] + node_remap_size[nid]));
 	}
 	printk("High memory starts at vaddr %08lx\n",
 			(ulong) pfn_to_kaddr(highstart_pfn));
@@ -439,3 +476,29 @@ int memory_add_physaddr_to_nid(u64 addr)
 
 EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
 #endif
+
+#ifndef CONFIG_HAVE_ARCH_PARSE_SRAT
+/*
+ * XXX FIXME: Make SLIT table parsing available to 32-bit NUMA
+ *
+ * These stub functions are needed to compile 32-bit NUMA when SRAT is
+ * not set. There are functions in srat_64.c for parsing this table
+ * and it may be possible to make them common functions.
+ */
+void acpi_numa_slit_init (struct acpi_table_slit *slit)
+{
+	printk(KERN_INFO "ACPI: No support for parsing SLIT table\n");
+}
+
+void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa)
+{
+}
+
+void acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma)
+{
+}
+
+void acpi_numa_arch_fixup(void)
+{
+}
+#endif /* CONFIG_HAVE_ARCH_PARSE_SRAT */

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[KOSAKI Motohiro]

Hi Mel


>To rule it out, can you also try with the patch below applied please? It
>should only make a difference on sparsemem so if discontigmem is still
>crashing, there is likely another problem. Assuming it crashes, please
>post the full dmesg output with loglevel=8 on the command line. Thanks

I buy reverse serial cable today.
and I test again.

my patch stack is
  2.6.24-rc7 +
  http://lkml.org/lkml/2007/8/24/220 +
  Relax restrictions on setting CONFIG_NUMA patch +
  your previous mail patch

1. if sparce_mem on, build failture

  CC      arch/x86/mm/discontig_32.o
  CC      init/do_mounts_initrd.o
  CC      arch/x86/kernel/time_32.o
  CC      init/initramfs.o
arch/x86/mm/discontig_32.c: In function 'setup_memory':
arch/x86/mm/discontig_32.c:341: error: too many arguments to function
'calculate_numa_remap_pages'
arch/x86/mm/discontig_32.c:380: error: 'node_remap_offset' undeclared
(first use in this function)
arch/x86/mm/discontig_32.c:380: error: (Each undeclared identifier is
reported only once
arch/x86/mm/discontig_32.c:380: error: for each function it appears in.)
arch/x86/mm/discontig_32.c:383: error: 'node_remap_end_vaddr'
undeclared (first use in this function)
arch/x86/mm/discontig_32.c:385: error: 'node_remap_alloc_vaddr'
undeclared (first use in this function)
arch/x86/mm/discontig_32.c:404: error: 'node_remap_start_pfn'
undeclared (first use in this function)

2. if discontig_mem on, I can't boot.

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-kosatest ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tt
y0 console=ttyS0,9600n8r loglevel=8
   [Linux-bzImage, setup=0x2800, size=0x278918]
initrd /initrd-kosatest.img
   [Linux-initrd @ 0x1f3bc000, 0x2c0208 bytes]

Linux version 2.6.24-rc7-numa (kosaki@sc420) (gcc version 4.1.2
20070626 (Red Hat 4.1.2-14)) #13 SMP Sat Jan 26 22:57:40 JST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001f68cc00 (usable)
 BIOS-e820: 000000001f68cc00 - 000000001f68ec00 (ACPI NVS)
 BIOS-e820: 000000001f68ec00 - 000000001f690c00 (ACPI data)
 BIOS-e820: 000000001f690c00 - 0000000020000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
Node: 0, start_pfn: 0, end_pfn: 160
  Setting physnode_map array to node 0 for pfns:
  0
Node: 0, start_pfn: 256, end_pfn: 128652
  Setting physnode_map array to node 0 for pfns:
  256 65792
get_memcfg_from_srat: assigning address to rsdp
RSD PTR  v0 [DELL  ]
Begin SRAT table scan....
failed to get NUMA memory information from SRAT table
NUMA - single node, flat memory mode
Node: 0, start_pfn: 0, end_pfn: 160
  Setting physnode_map array to node 0 for pfns:
  0
Node: 0, start_pfn: 256, end_pfn: 128652
  Setting physnode_map array to node 0 for pfns:
  256 65792
Node: 0, start_pfn: 0, end_pfn: 128652
  Setting physnode_map array to node 0 for pfns:
  0 65536
Reserving 1024 pages of KVA for lmem_map of node 0
Shrinking node 0 from 128652 pages to 127628 pages
Shrinking node 0 further by 652 pages for proper alignment
Reserving total of 1024 pages for numa KVA remap
kva_start_pfn ~ 125952 find_max_low_pfn() ~ 128652
max_pfn = 128652
0MB HIGHMEM available.
502MB LOWMEM available.
min_low_pfn = 1665, max_low_pfn = 128652, highstart_pfn = 128652
Low memory ends at vaddr df68c000
node 0 will remap to vaddr dec00000 - dfa8c000
High memory starts at vaddr df68c000
found SMP MP-table at 000fe710
Entering add_active_range(0, 0, 126976) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   128652
  HighMem    128652 ->   128652
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   126976
On node 0 totalpages: 126976
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 960 pages used for memmap
  Normal zone: 121920 pages, LIFO batch:31
  HighMem zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
DMI 2.3 present.
Using APIC driver default
ACPI: RSDP 000FEC00, 0014 (r0 DELL  )
ACPI: RSDT 000FCC8F, 003C (r1 DELL    PESC420        7 ASL        61)
ACPI: FACP 000FCCCB, 0074 (r1 DELL    PESC420        7 ASL        61)
ACPI: DSDT FFFCE00E, 2DA9 (r1   DELL    dt_ex     1000 MSFT  100000D)
ACPI: FACS 1F68CC00, 0040
ACPI: SSDT FFFD0FAE, 0096 (r1   DELL    st_ex     1000 MSFT  100000D)
ACPI: APIC 000FCD3F, 0072 (r1 DELL    PESC420        7 ASL        61)
ACPI: BOOT 000FCDB1, 0028 (r1 DELL    PESC420        7 ASL        61)
ACPI: MCFG 000FCDD9, 003E (r1 DELL    PESC420        7 ASL        61)
ACPI: HPET 000FCE17, 0038 (r1 DELL    PESC420        7 ASL        61)
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] disabled)
ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 125984
Policy zone: Normal
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet
console=tty0 console=ttyS0,9600n8r loglevel=8
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 2793.181 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Bad page state in process 'swapper'
page:defe2000 flags:0x763aaa3a mapping:3dda44a6 mapcount:-479800631 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-numa #13
 [<c014da0b>] bad_page+0x64/0x8e
 [<c014e6af>] __free_pages_ok+0x5d/0x2ad
 [<c05af4f2>] free_all_bootmem_core+0xd5/0x1b1
 [<c05ac932>] mem_init+0x7f/0x351
 [<c05b0a25>] alloc_large_system_hash+0x21a/0x245
 [<c05b1947>] inode_init_early+0x49/0x72
 [<c059f5ca>] start_kernel+0x281/0x30c
 [<c059f0e0>] unknown_bootoption+0x0/0x195
 =======================
BUG: unable to handle kernel paging request at virtual address 2b021d5a
printing eip: c014e694 *pde = 00000000
Oops: 0000 [#1] SMP
Modules linked in:

Pid: 0, comm: swapper Tainted: G    B   (2.6.24-rc7-numa #13)
EIP: 0060:[<c014e694>] EFLAGS: 00010246 CPU: 0
EIP is at __free_pages_ok+0x42/0x2ad
EAX: 00000000 EBX: defe2020 ECX: 2b021d56 EDX: 4e20ad11
ESI: 4e20ad0f EDI: 00000000 EBP: defe2000 ESP: c0599f0c
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c0598000 task=c053f3a0 task.ti=c0598000)
Stack: 00000005 00000287 00000001 00000002 00000200 00000009 0000000a dec233e0
       ffffffff 0001f000 00000000 c05af4f2 c0683000 c05f6520 0001f000 0001e599
       0001f68c 00000001 00000000 00000000 00000000 00000020 c05ac932 c04d1437
Call Trace:
 [<c05af4f2>] free_all_bootmem_core+0xd5/0x1b1
 [<c05ac932>] mem_init+0x7f/0x351
 [<c05b0a25>] alloc_large_system_hash+0x21a/0x245
 [<c05b1947>] inode_init_early+0x49/0x72
 [<c059f5ca>] start_kernel+0x281/0x30c
 [<c059f0e0>] unknown_bootoption+0x0/0x195
 =======================
Code: 00 eb 5e 8b 03 89 d9 8b 73 08 8b 53 10 25 00 40 02 00 3d 00 40
02 00 75 03 8b 4b 0c 85 d2 0f 95 c2 8d 46 01 0f b6 d2 09 c2 31 c0 <83>
79 04 00 0f 95 c0 09 c2 8b 03 25 e1 9c 08 00 09 c2 74 07 89
EIP: [<c014e694>] __free_pages_ok+0x42/0x2ad SS:ESP 0068:c0599f0c
---[ end trace ca143223eefdc828 ]---
Kernel panic - not syncing: Attempted to kill the idle task!


panic point is below line (I invested by compare EIP and disassenble list.)

static void __free_pages_ok(struct page *page, unsigned int order)
{
        unsigned long flags;
        int i;
        int reserved = 0;

        for (i = 0 ; i < (1 << order) ; ++i)
                reserved += free_pages_check(page + i);    // here!
        if (reserved)
                return;


thanks!

--
kosaki

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[KOSAKI Motohiro]

> 1. if sparce_mem on, build failture

after fix compile error, no panic and bad-page happened both highmem
off and 64G.
I guess discontigmem numa is premature yet ;-)

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (26/01/08 23:10), KOSAKI Motohiro didst pronounce:
> Hi Mel
> 
> 
> >To rule it out, can you also try with the patch below applied please? It
> >should only make a difference on sparsemem so if discontigmem is still
> >crashing, there is likely another problem. Assuming it crashes, please
> >post the full dmesg output with loglevel=8 on the command line. Thanks
> 
> I buy reverse serial cable today.
> and I test again.
> 

Great

> my patch stack is
>   2.6.24-rc7 +
>   http://lkml.org/lkml/2007/8/24/220 +

Can you replace this patch with the patch below instead and try again
please? This is the patch that is actually in git-x86. Out of
curiousity, have you tried the latest mm branch from git-x86?

commit c824d2f33bf41e806cc975e659a711ba14927b62
diff --git a/arch/x86/mm/discontig_32.c b/arch/x86/mm/discontig_32.c
index 88a7499..9f1d02c 100644
--- a/arch/x86/mm/discontig_32.c
+++ b/arch/x86/mm/discontig_32.c
@@ -268,6 +268,7 @@ unsigned long __init setup_memory(void)
 {
 	int nid;
 	unsigned long system_start_pfn, system_max_low_pfn;
+	unsigned long wasted_pages;
 
 	/*
 	 * When mapping a NUMA machine we allocate the node_mem_map arrays
@@ -292,7 +293,14 @@ unsigned long __init setup_memory(void)
 		kva_start_pfn = PFN_DOWN(initrd_start - PAGE_OFFSET)
 			- kva_pages;
 #endif
-	kva_start_pfn -= kva_start_pfn & (PTRS_PER_PTE-1);
+
+	/*
+	 * We waste pages past at the end of the KVA for no good reason other
+	 * than how it is located. This is bad.
+	 */
+	wasted_pages = kva_start_pfn & (PTRS_PER_PTE-1);
+	kva_start_pfn -= wasted_pages;
+	kva_pages += wasted_pages;
 
 	system_max_low_pfn = max_low_pfn = find_max_low_pfn();
 	printk("kva_start_pfn ~ %ld find_max_low_pfn() ~ %ld\n",
@@ -345,7 +353,8 @@ unsigned long __init setup_memory(void)
 
 void __init numa_kva_reserve(void)
 {
-	reserve_bootmem(PFN_PHYS(kva_start_pfn),PFN_PHYS(kva_pages));
+	if (kva_pages)
+		reserve_bootmem(PFN_PHYS(kva_start_pfn), PFN_PHYS(kva_pages));
 }
 
 void __init zone_sizes_init(void)

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[KOSAKI Motohiro]

Hi Mel

> > my patch stack is
> >   2.6.24-rc7 +
> >   http://lkml.org/lkml/2007/8/24/220 +
>
> Can you replace this patch with the patch below instead and try again
> please? This is the patch that is actually in git-x86. Out of
> curiousity, have you tried the latest mm branch from git-x86?

to be honest, I didn't understand usage of git, sorry.
I learned method of git checkout today and test again (head of git-x86
+ your previous patch).

result
       -> panic again.

-------------------------------------------------------------------------------------------
  Booting 'kosatest'

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-kosatest ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tt
y0 console=ttyS0,9600n8r
   [Linux-bzImage, setup=0x2800, size=0x27bd58]
initrd /initrd-kosatest.img
   [Linux-initrd @ 0x1f3bc000, 0x2c052c bytes]

Bad page state in process 'swapper'
page:c13ecfa0 flags:0x00000000 mapping:00000000 mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Bad page state in process 'swapper'
page:c13ecfc0 flags:0x00000000 mapping:00000000 mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Bad page state in process 'swapper'
page:c13ecfe0 flags:0x00000000 mapping:00000000 mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Bad page state in process 'swapper'
page:c13ed000 flags:0xfffedb08 mapping:00000000 mapcount:1 count:-268393021
Trying to fix it up, but a reboot is needed
Backtrace:
BUG: unable to handle kernel paging request at virtual address f000a5c7
printing eip: c014d9b8 *pdpt = 0000000000004001 *pde = 0000000000000000
Oops: 0002 [#1] SMP
Modules linked in:

Pid: 0, comm: swapper Tainted: G    B   (2.6.24-g34984208-dirty #3)
EIP: 0060:[<c014d9b8>] EFLAGS: 00010016 CPU: 0
EIP is at free_hot_cold_page+0xe8/0x14b
EAX: c13ed018 EBX: c13ed000 ECX: 0000000c EDX: f000a5c3
ESI: 00000000 EDI: 00000246 EBP: 00000c00 ESP: c059bf24
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c059a000 task=c05443a0 task.ti=c059a000)
Stack: 00000000 c13ed000 00000fff 0001f680 00000001 c05b19cb c0686000 c05fa520
       0001f680 0001e590 0001f68c 00000001 00000000 00000000 00000000 00000020
       c05ae9dd c04d59e6 c059bf7c c059bf7c c05b2eca c04d59e6 c04d7a11 00008000
Call Trace:
 [<c05b19cb>] free_all_bootmem_core+0x115/0x1b1
 [<c05ae9dd>] mem_init+0x7f/0x368
 [<c05b2eca>] alloc_large_system_hash+0x226/0x251
 [<c05b3dfc>] inode_init_early+0x49/0x72
 [<c05a15ca>] start_kernel+0x281/0x30c
 [<c05a10e0>] unknown_bootoption+0x0/0x195
 =======================
Code: 75 7a 6b f7 14 64 a1 08 40 5e c0 03 74 85 28 9c 5f fa 64 8b 15
10 61 5e c0 b8 40 74 5e c0 ff 44 02 20 8b 56 0c 8d 43 18 8d 4e 0c <89>
42 04 89 53 18 89 48 04 89 46 0c 31 c0 83 3d 98 83 59 c0 00
EIP: [<c014d9b8>] free_hot_cold_page+0xe8/0x14b SS:ESP 0068:c059bf24
---[ end trace ca143223eefdc828 ]---
Kernel panic - not syncing: Attempted to kill the idle task!

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Ingo Molnar]

* KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:

> > Can you replace this patch with the patch below instead and try 
> > again please? This is the patch that is actually in git-x86. Out of 
> > curiousity, have you tried the latest mm branch from git-x86?
> 
> to be honest, I didn't understand usage of git, sorry. I learned 
> method of git checkout today and test again (head of git-x86 + your 
> previous patch).

here's a QuickStart:

   http://redhat.com/~mingo/x86.git/README

	Ingo

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[KOSAKI Motohiro]

> here's a QuickStart:
> 
>    http://redhat.com/~mingo/x86.git/README

Thanks!

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[Mel Gorman]

On (27/01/08 15:54), KOSAKI Motohiro didst pronounce:
> Hi Mel
> 
> > > my patch stack is
> > >   2.6.24-rc7 +
> > >   http://lkml.org/lkml/2007/8/24/220 +
> >
> > Can you replace this patch with the patch below instead and try again
> > please? This is the patch that is actually in git-x86. Out of
> > curiousity, have you tried the latest mm branch from git-x86?
> 
> to be honest, I didn't understand usage of git, sorry.

It's ok. Ingo sent you a helpful guide. In it, it covers how to check
out the mm branch; see this part

#
# Check out the latest x86 branch:
#
git-checkout x86/mm

This is the branch that contains all the latest patches. You should *not*
need to patch it further. If your machine fails to boot this branch then
I'll need to roll a debugging patch. Before I do that, I want to be sure
you are testing the right branch.

Thanks for persisting. I know this is a little frustrating.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

[KOSAKI Motohiro]

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

Hi Mel

> This is the branch that contains all the latest patches. You should *not*
> need to patch it further. If your machine fails to boot this branch then
> I'll need to roll a debugging patch. Before I do that, I want to be sure
> you are testing the right branch.

sorry for late responce and thank you for git advise.
I tested x86/mm.

but, it doesn't works yet.

PAE + NUMA + discontigmem: boot failure
PAE + NUMA + sparsemem:    boot success

I attached log, .config and checkout script.

thanks again.

[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 9593 bytes --]

[-- Attachment #3: discontigmem.log --]
[-- Type: application/octet-stream, Size: 12413 bytes --]

  Booting 'log8'

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-kosatest ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tt
y0 console=ttyS0,9600n8r loglevel=8
   [Linux-bzImage, setup=0x2a00, size=0x29cee0]
initrd /initrd-kosatest.img
   [Linux-initrd @ 0x1f3bc000, 0x2c066a bytes]

Linux version 2.6.24-x86numa-06390-g7d8f371 (kosaki@sc420) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)) #3 SMP Sun Feb 3 17:50:15 JST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001f68cc00 (usable)
 BIOS-e820: 000000001f68cc00 - 000000001f68ec00 (ACPI NVS)
 BIOS-e820: 000000001f68ec00 - 000000001f690c00 (ACPI data)
 BIOS-e820: 000000001f690c00 - 0000000020000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
Node: 0, start_pfn: 0, end_pfn: 160
  Setting physnode_map array to node 0 for pfns:
  0
Node: 0, start_pfn: 256, end_pfn: 128652
  Setting physnode_map array to node 0 for pfns:
  256 65792
get_memcfg_from_srat: assigning address to rsdp
RSD PTR  v0 [DELL  ]
Begin SRAT table scan....
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:434 early_ioremap+0x76/0x157()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.24-x86numa-06390-g7d8f371 #3
 [<c0124168>] warn_on_slowpath+0x41/0x51
 [<c01248d5>] ? release_console_sem+0x1a8/0x1bb
 [<c01248d5>] ? release_console_sem+0x1a8/0x1bb
 [<c03e374b>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c01248e0>] ? release_console_sem+0x1b3/0x1bb
 [<c01248d5>] ? release_console_sem+0x1a8/0x1bb
 [<c01248e0>] ? release_console_sem+0x1b3/0x1bb
 [<c05827b9>] early_ioremap+0x76/0x157
 [<c0580fd9>] get_memcfg_from_srat+0x143/0x581
 [<c0124de4>] ? printk+0x15/0x17
 [<c0582b29>] setup_memory+0x13/0x438
 [<c020e088>] ? strlcpy+0x13/0x3e
 [<c057a3a9>] setup_arch+0x22a/0x3b0
 [<c0124de4>] ? printk+0x15/0x17
 [<c0574655>] start_kernel+0x6c/0x31d
 =======================
---[ end trace ca143223eefdc828 ]---
failed to get NUMA memory information from SRAT table
NUMA - single node, flat memory mode
Node: 0, start_pfn: 0, end_pfn: 160
  Setting physnode_map array to node 0 for pfns:
  0
Node: 0, start_pfn: 256, end_pfn: 128652
  Setting physnode_map array to node 0 for pfns:
  256 65792
Node: 0, start_pfn: 0, end_pfn: 128652
  Setting physnode_map array to node 0 for pfns:
  0 65536
Reserving 512 pages of KVA for lmem_map of node 0
Shrinking node 0 from 128652 pages to 128140 pages
Shrinking node 0 further by 140 pages for proper alignment
Reserving total of 512 pages for numa KVA remap
kva_start_pfn ~ 128000 find_max_low_pfn() ~ 128652
max_pfn = 128652
0MB HIGHMEM available.
502MB LOWMEM available.
min_low_pfn = 2225, max_low_pfn = 128652, highstart_pfn = 128652
Low memory ends at vaddr df68c000
node 0 will remap to vaddr df400000 - df88c000
High memory starts at vaddr df68c000
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
found SMP MP-table at [c00fe710] 000fe710
NX (Execute Disable) protection: active
Entering add_active_range(0, 0, 128000) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   128652
  HighMem    128652 ->   128652
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   128000
On node 0 totalpages: 128000
  DMA zone: 56 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4040 pages, LIFO batch:0
  Normal zone: 1694 pages used for memmap
  Normal zone: 122210 pages, LIFO batch:31
  HighMem zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:434 early_ioremap+0x76/0x157()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.24-x86numa-06390-g7d8f371 #3
 [<c0124168>] warn_on_slowpath+0x41/0x51
 [<c01248d5>] ? release_console_sem+0x1a8/0x1bb
 [<c03e374b>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c01248e0>] ? release_console_sem+0x1b3/0x1bb
 [<c0596f9f>] ? __absent_pages_in_range+0x15/0x9e
 [<c013d38b>] ? lockdep_init_map+0x7a/0x30f
 [<c0212436>] ? __spin_lock_init+0x24/0x48
 [<c05827b9>] early_ioremap+0x76/0x157
 [<c0590506>] dmi_scan_machine+0x18/0x1bd
 [<c05865e0>] ? free_area_init_nodes+0x25a/0x26d
 [<c0582a12>] ? zone_sizes_init+0x94/0x9a
 [<c057a4f1>] setup_arch+0x372/0x3b0
 [<c0574655>] start_kernel+0x6c/0x31d
 =======================
---[ end trace ca143223eefdc828 ]---
DMI not present or invalid.
Using APIC driver default
ACPI: RSDP 000FEC00, 0014 (r0 DELL  )
ACPI: RSDT 000FCC8F, 003C (r1 DELL    PESC420        7 ASL        61)
ACPI: FACP 000FCCCB, 0074 (r1 DELL    PESC420        7 ASL        61)
ACPI: DSDT FFFCE00E, 2DA9 (r1   DELL    dt_ex     1000 MSFT  100000D)
ACPI: FACS 1F68CC00, 0040
ACPI: SSDT FFFD0FAE, 0096 (r1   DELL    st_ex     1000 MSFT  100000D)
ACPI: APIC 000FCD3F, 0072 (r1 DELL    PESC420        7 ASL        61)
ACPI: BOOT 000FCDB1, 0028 (r1 DELL    PESC420        7 ASL        61)
ACPI: MCFG 000FCDD9, 003E (r1 DELL    PESC420        7 ASL        61)
ACPI: HPET 000FCE17, 0038 (r1 DELL    PESC420        7 ASL        61)
ACPI: no DMI BIOS year, acpi=force is required to enable ACPI
ACPI: Disabling ACPI support
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: DELL     Product ID: PE SC420     APIC at: 0xFEE00000
Processor #0 15:4 APIC version 20
I/O APIC #8 Version 32 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 126250
Policy zone: Normal
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,9600n8r loglevel=8
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 2793.259 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 1024 kB
 per task-struct memory footprint: 1680 bytes
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Initializing HighMem for node 0 (00000000:00000000)
Memory: 495544k/514608k available (2971k kernel code, 16872k reserved, 1561k data, 580k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffe14000 - 0xfffff000   (1964 kB)
    pkmap   : 0xffa00000 - 0xffc00000   (2048 kB)
    vmalloc : 0xe0000000 - 0xff9fe000   ( 505 MB)
    lowmem  : 0xc0000000 - 0xdf68c000   ( 502 MB)
      .init : 0xc0574000 - 0xc0605000   ( 580 kB)
      .data : 0xc03e6dd2 - 0xc056d53c   (1561 kB)
      .text : 0xc0100000 - 0xc03e6dd2   (2971 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
SLUB: Genslabs=12, HWalign=128, Order=0-1, MinObjects=4, CPUs=1, Nodes=8
Calibrating delay using timer specific routine.. 5595.38 BogoMIPS (lpj=11190767)
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 15k freed
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 01
Mapping cpu 0 to node 0
Total of 1 processors activated (5595.38 BogoMIPS).
ExtINT not setup in hardware but reported by MP table
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
Brought up 1 CPUs
CPU0 attaching sched-domain:
 domain 0: span 00000001
  groups: 00000001
net_namespace: 320 bytes
NET: Registered protocol family 16
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 0880-08bf claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/2640] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:1d.0[A] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:1d.1[B] -> IRQ 22
PCI->APIC IRQ transform: 0000:00:1d.2[C] -> IRQ 18
PCI->APIC IRQ transform: 0000:00:1d.3[D] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:1d.7[A] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:1f.1[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:00:1f.2[C] -> IRQ 20
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 17
PCI->APIC IRQ transform: 0000:02:00.0[A] -> IRQ 16
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: dfe00000-dfefffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: dfd00000-dfdfffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
  IO window: disabled.
  MEM window: dfc00000-dfcfffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 7, 589824 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
checking if image is initramfs... it is
------------[ cut here ]------------
kernel BUG at mm/page_alloc.c:1698!
invalid opcode: 0000 [#1] SMP
Modules linked in:

Pid: 1, comm: swapper Not tainted (2.6.24-x86numa-06390-g7d8f371 #3)
EIP: 0060:[<c01547c3>] EFLAGS: 00010246 CPU: 0
EIP is at free_pages+0x39/0x56
EAX: 0001f400 EBX: 00000000 ECX: c08b1000 EDX: 0001f400
ESI: df400000 EDI: df401000 EBP: dec25f48 ESP: dec25f44
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 1, ti=dec24000 task=dec22000 task.ti=dec24000)
Stack: c08b1000 dec25f68 c0116119 df67c66a c0499691 002c066a 00000000 c0000000
       df3bc000 dec25f70 c011615a dec25f84 c057803d 00000000 00000000 00000000
       dec25f94 c0579248 c049170c 00000000 dec25fe0 c057449f c172ae80 dec22000
Call Trace:
 [<c0116119>] ? free_init_pages+0x95/0xc5
 [<c011615a>] ? free_initrd_mem+0x11/0x13
 [<c057803d>] ? free_initrd+0x7e/0x97
 [<c0579248>] ? populate_rootfs+0x7b/0xcd
 [<c057449f>] ? kernel_init+0x147/0x291
 [<c0574358>] ? kernel_init+0x0/0x291
 [<c0574358>] ? kernel_init+0x0/0x291
 [<c01058af>] ? kernel_thread_helper+0x7/0x10
 =======================
Code: 40 89 c2 c1 e8 1c 0f be 80 40 ba 56 c0 c1 ea 0c 85 c0 78 17 8b 0c 85 80 bb 56 c0 8b 81 8c 18 00 00 03 81 94 18 00 00 39 c2 72 04 <0f> 0b eb fe 2b 91 8c 18 00 00 6b c2 38 89 da 03 81 84 18 00 00
EIP: [<c01547c3>] free_pages+0x39/0x56 SS:ESP 0068:dec25f44
---[ end trace ca143223eefdc828 ]---
Kernel panic - not syncing: Attempted to kill init!

[-- Attachment #4: sparsemem.log --]
[-- Type: application/octet-stream, Size: 32482 bytes --]


  Booting 'log8'

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-kosatest ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tt
y0 console=ttyS0,9600n8r loglevel=8
   [Linux-bzImage, setup=0x2a00, size=0x29cca0]
initrd /initrd-kosatest.img
   [Linux-initrd @ 0x1f3bb000, 0x2c0c3f bytes]

Linux version 2.6.24-x86numa-06390-g7d8f371 (kosaki@sc420) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)) #2 SMP Sun Feb 3 16:48:45 JST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001f68cc00 (usable)
 BIOS-e820: 000000001f68cc00 - 000000001f68ec00 (ACPI NVS)
 BIOS-e820: 000000001f68ec00 - 000000001f690c00 (ACPI data)
 BIOS-e820: 000000001f690c00 - 0000000020000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
get_memcfg_from_srat: assigning address to rsdp
RSD PTR  v0 [DELL  ]
Begin SRAT table scan....
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:434 early_ioremap+0x76/0x157()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.24-x86numa-06390-g7d8f371 #2
 [<c0124014>] warn_on_slowpath+0x41/0x51
 [<c0124781>] ? release_console_sem+0x1a8/0x1bb
 [<c0124781>] ? release_console_sem+0x1a8/0x1bb
 [<c03e30bb>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c012478c>] ? release_console_sem+0x1b3/0x1bb
 [<c0124781>] ? release_console_sem+0x1a8/0x1bb
 [<c03e30bb>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c05827b4>] early_ioremap+0x76/0x157
 [<c0580fde>] get_memcfg_from_srat+0x143/0x581
 [<c058dd51>] ? setup_early_serial8250_console+0x25/0x321
 [<c012478c>] ? release_console_sem+0x1b3/0x1bb
 [<c0582a7a>] setup_memory+0xf/0x278
 [<c057a3a9>] setup_arch+0x22a/0x3b5
 [<c0124c90>] ? printk+0x15/0x17
 [<c0574655>] start_kernel+0x6c/0x31d
 =======================
---[ end trace ca143223eefdc828 ]---
failed to get NUMA memory information from SRAT table
NUMA - single node, flat memory mode
kva_start_pfn ~ 128512 find_max_low_pfn() ~ 128652
max_pfn = 128652
0MB HIGHMEM available.
502MB LOWMEM available.
min_low_pfn = 2225, max_low_pfn = 128652, highstart_pfn = 128652
Low memory ends at vaddr df68c000
High memory starts at vaddr df68c000
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
found SMP MP-table at [c00fe710] 000fe710
NX (Execute Disable) protection: active
Entering add_active_range(0, 0, 128652) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   128652
  HighMem    128652 ->   128652
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   128652
On node 0 totalpages: 128652
  DMA zone: 56 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4040 pages, LIFO batch:0
  Normal zone: 1702 pages used for memmap
  Normal zone: 122854 pages, LIFO batch:31
  HighMem zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:434 early_ioremap+0x76/0x157()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.24-x86numa-06390-g7d8f371 #2
 [<c0124014>] warn_on_slowpath+0x41/0x51
 [<c0120037>] ? idle_task_exit+0x6d/0x10f
 [<c03e30bb>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c012478c>] ? release_console_sem+0x1b3/0x1bb
 [<c0152d53>] ? set_pageblock_flags_group+0x11/0x66
 [<c0596e36>] ? __absent_pages_in_range+0x15/0x9e
 [<c013d24b>] ? lockdep_init_map+0x7a/0x30f
 [<c0212046>] ? __spin_lock_init+0x24/0x48
 [<c05827b4>] early_ioremap+0x76/0x157
 [<c0590433>] dmi_scan_machine+0x18/0x1bd
 [<c0586368>] ? free_area_init_nodes+0x25a/0x26d
 [<c05829f5>] ? zone_sizes_init+0x94/0x9a
 [<c057a4f6>] setup_arch+0x377/0x3b5
 [<c0574655>] start_kernel+0x6c/0x31d
 =======================
---[ end trace ca143223eefdc828 ]---
DMI not present or invalid.
Using APIC driver default
ACPI: RSDP 000FEC00, 0014 (r0 DELL  )
ACPI: RSDT 000FCC8F, 003C (r1 DELL    PESC420        7 ASL        61)
ACPI: FACP 000FCCCB, 0074 (r1 DELL    PESC420        7 ASL        61)
ACPI: DSDT FFFCE00E, 2DA9 (r1   DELL    dt_ex     1000 MSFT  100000D)
ACPI: FACS 1F68CC00, 0040
ACPI: SSDT FFFD0FAE, 0096 (r1   DELL    st_ex     1000 MSFT  100000D)
ACPI: APIC 000FCD3F, 0072 (r1 DELL    PESC420        7 ASL        61)
ACPI: BOOT 000FCDB1, 0028 (r1 DELL    PESC420        7 ASL        61)
ACPI: MCFG 000FCDD9, 003E (r1 DELL    PESC420        7 ASL        61)
ACPI: HPET 000FCE17, 0038 (r1 DELL    PESC420        7 ASL        61)
ACPI: no DMI BIOS year, acpi=force is required to enable ACPI
ACPI: Disabling ACPI support
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: DELL     Product ID: PE SC420     APIC at: 0xFEE00000
Processor #0 15:4 APIC version 20
I/O APIC #8 Version 32 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 126894
Policy zone: Normal
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,9600n8r loglevel=8
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 2793.188 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 1024 kB
 per task-struct memory footprint: 1680 bytes
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Initializing HighMem for node 0 (00000000:00000000)
Memory: 488204k/514608k available (2969k kernel code, 26020k reserved, 1563k data, 580k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffe14000 - 0xfffff000   (1964 kB)
    pkmap   : 0xffa00000 - 0xffc00000   (2048 kB)
    vmalloc : 0xe0000000 - 0xff9fe000   ( 505 MB)
    lowmem  : 0xc0000000 - 0xdf68c000   ( 502 MB)
      .init : 0xc0574000 - 0xc0605000   ( 580 kB)
      .data : 0xc03e6728 - 0xc056d4bc   (1563 kB)
      .text : 0xc0100000 - 0xc03e6728   (2969 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
SLUB: Genslabs=12, HWalign=128, Order=0-1, MinObjects=4, CPUs=1, Nodes=8
Calibrating delay using timer specific routine.. 5595.26 BogoMIPS (lpj=11190527)
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 15k freed
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 01
Mapping cpu 0 to node 0
Total of 1 processors activated (5595.26 BogoMIPS).
ExtINT not setup in hardware but reported by MP table
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
Brought up 1 CPUs
CPU0 attaching sched-domain:
 domain 0: span 00000001
  groups: 00000001
net_namespace: 320 bytes
NET: Registered protocol family 16
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 0880-08bf claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/2640] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:1d.0[A] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:1d.1[B] -> IRQ 22
PCI->APIC IRQ transform: 0000:00:1d.2[C] -> IRQ 18
PCI->APIC IRQ transform: 0000:00:1d.3[D] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:1d.7[A] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:1f.1[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:00:1f.2[C] -> IRQ 20
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 17
PCI->APIC IRQ transform: 0000:02:00.0[A] -> IRQ 16
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: dfe00000-dfefffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: dfd00000-dfdfffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
  IO window: disabled.
  MEM window: dfc00000-dfcfffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 7, 589824 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 2819k freed
Simple Boot Flag at 0x7a set to 0x1
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
Total HugeTLB memory allocated, 0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Boot video device is 0000:00:02.0
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:01.0:pcie00]
Allocate Port Service[0000:00:01.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
Allocate Port Service[0000:00:1c.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.1:pcie00]
Allocate Port Service[0000:00:1c.1:pcie02]
Allocate Port Service[0000:00:1c.1:pcie03]
Real Time Clock Driver v1.12ac
intel_rng: Firmware space is locked read-only. If you can't or
intel_rng: don't want to disable this in firmware setup, and if
intel_rng: you are certain that your system has a functional
intel_rng: RNG, try using the 'no_fwh_detect' option.
Linux agpgart interface v0.102
agpgart: Detected an Intel E7221 (i915) Chipset.
agpgart: Detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xf0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
Copyright (c) 1999-2006 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
tg3.c:v3.87 (December 20, 2007)
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: Tigon3 [partno(BCM95751) rev 4001 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:13:20:2f:3f:b2
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76180000] dma_mask[64-bit]
console [netcon0] enabled
Linux version 2.6.24-x86numa-06390-g7d8f371 (kosaki@sc420) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)) #2 SMP Sun Feb 3 16:48:45 JST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001f68cc00 (usable)
 BIOS-e820: 000000001f68cc00 - 000000001f68ec00 (ACPI NVS)
 BIOS-e820: 000000001f68ec00 - 000000001f690c00 (ACPI data)
 BIOS-e820: 000000001f690c00 - 0000000020000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
get_memcfg_from_srat: assigning address to rsdp
RSD PTR  v0 [DELL  ]
Begin SRAT table scan....
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:434 early_ioremap+0x76/0x157()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.24-x86numa-06390-g7d8f371 #2
 [<c0124014>] warn_on_slowpath+0x41/0x51
 [<c0124781>] ? release_console_sem+0x1a8/0x1bb
 [<c0124781>] ? release_console_sem+0x1a8/0x1bb
 [<c03e30bb>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c012478c>] ? release_console_sem+0x1b3/0x1bb
 [<c0124781>] ? release_console_sem+0x1a8/0x1bb
 [<c03e30bb>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c05827b4>] early_ioremap+0x76/0x157
 [<c0580fde>] get_memcfg_from_srat+0x143/0x581
 [<c058dd51>] ? setup_early_serial8250_console+0x25/0x321
 [<c012478c>] ? release_console_sem+0x1b3/0x1bb
 [<c0582a7a>] setup_memory+0xf/0x278
 [<c057a3a9>] setup_arch+0x22a/0x3b5
 [<c0124c90>] ? printk+0x15/0x17
 [<c0574655>] start_kernel+0x6c/0x31d
 =======================
---[ end trace ca143223eefdc828 ]---
failed to get NUMA memory information from SRAT table
NUMA - single node, flat memory mode
kva_start_pfn ~ 128512 find_max_low_pfn() ~ 128652
max_pfn = 128652
0MB HIGHMEM available.
502MB LOWMEM available.
min_low_pfn = 2225, max_low_pfn = 128652, highstart_pfn = 128652
Low memory ends at vaddr df68c000
High memory starts at vaddr df68c000
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
found SMP MP-table at [c00fe710] 000fe710
NX (Execute Disable) protection: active
Entering add_active_range(0, 0, 128652) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   128652
  HighMem    128652 ->   128652
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   128652
On node 0 totalpages: 128652
  DMA zone: 56 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4040 pages, LIFO batch:0
  Normal zone: 1702 pages used for memmap
  Normal zone: 122854 pages, LIFO batch:31
  HighMem zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:434 early_ioremap+0x76/0x157()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.24-x86numa-06390-g7d8f371 #2
 [<c0124014>] warn_on_slowpath+0x41/0x51
 [<c0120037>] ? idle_task_exit+0x6d/0x10f
 [<c03e30bb>] ? _spin_unlock_irqrestore+0x2f/0x3c
 [<c012478c>] ? release_console_sem+0x1b3/0x1bb
 [<c0152d53>] ? set_pageblock_flags_group+0x11/0x66
 [<c0596e36>] ? __absent_pages_in_range+0x15/0x9e
 [<c013d24b>] ? lockdep_init_map+0x7a/0x30f
 [<c0212046>] ? __spin_lock_init+0x24/0x48
 [<c05827b4>] early_ioremap+0x76/0x157
 [<c0590433>] dmi_scan_machine+0x18/0x1bd
 [<c0586368>] ? free_area_init_nodes+0x25a/0x26d
 [<c05829f5>] ? zone_sizes_init+0x94/0x9a
 [<c057a4f6>] setup_arch+0x377/0x3b5
 [<c0574655>] start_kernel+0x6c/0x31d
 =======================
---[ end trace ca143223eefdc828 ]---
DMI not present or invalid.
Using APIC driver default
ACPI: RSDP 000FEC00, 0014 (r0 DELL  )
ACPI: RSDT 000FCC8F, 003C (r1 DELL    PESC420        7 ASL        61)
ACPI: FACP 000FCCCB, 0074 (r1 DELL    PESC420        7 ASL        61)
ACPI: DSDT FFFCE00E, 2DA9 (r1   DELL    dt_ex     1000 MSFT  100000D)
ACPI: FACS 1F68CC00, 0040
ACPI: SSDT FFFD0FAE, 0096 (r1   DELL    st_ex     1000 MSFT  100000D)
ACPI: APIC 000FCD3F, 0072 (r1 DELL    PESC420        7 ASL        61)
ACPI: BOOT 000FCDB1, 0028 (r1 DELL    PESC420        7 ASL        61)
ACPI: MCFG 000FCDD9, 003E (r1 DELL    PESC420        7 ASL        61)
ACPI: HPET 000FCE17, 0038 (r1 DELL    PESC420        7 ASL        61)
ACPI: no DMI BIOS year, acpi=force is required to enable ACPI
ACPI: Disabling ACPI support
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: DELL     Product ID: PE SC420     APIC at: 0xFEE00000
Processor #0 15:4 APIC version 20
I/O APIC #8 Version 32 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 126894
Policy zone: Normal
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,9600n8r loglevel=8
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 2793.188 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 1024 kB
 per task-struct memory footprint: 1680 bytes
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Initializing HighMem for node 0 (00000000:00000000)
Memory: 488204k/514608k available (2969k kernel code, 26020k reserved, 1563k data, 580k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffe14000 - 0xfffff000   (1964 kB)
    pkmap   : 0xffa00000 - 0xffc00000   (2048 kB)
    vmalloc : 0xe0000000 - 0xff9fe000   ( 505 MB)
    lowmem  : 0xc0000000 - 0xdf68c000   ( 502 MB)
      .init : 0xc0574000 - 0xc0605000   ( 580 kB)
      .data : 0xc03e6728 - 0xc056d4bc   (1563 kB)
      .text : 0xc0100000 - 0xc03e6728   (2969 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
SLUB: Genslabs=12, HWalign=128, Order=0-1, MinObjects=4, CPUs=1, Nodes=8
Calibrating delay using timer specific routine.. 5595.26 BogoMIPS (lpj=11190527)
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 15k freed
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 01
Mapping cpu 0 to node 0
Total of 1 processors activated (5595.26 BogoMIPS).
ExtINT not setup in hardware but reported by MP table
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
Brought up 1 CPUs
CPU0 attaching sched-domain:
 domain 0: span 00000001
  groups: 00000001
net_namespace: 320 bytes
NET: Registered protocol family 16
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 0880-08bf claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/2640] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:1d.0[A] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:1d.1[B] -> IRQ 22
PCI->APIC IRQ transform: 0000:00:1d.2[C] -> IRQ 18
PCI->APIC IRQ transform: 0000:00:1d.3[D] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:1d.7[A] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:1f.1[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:00:1f.2[C] -> IRQ 20
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 17
PCI->APIC IRQ transform: 0000:02:00.0[A] -> IRQ 16
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: dfe00000-dfefffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: dfd00000-dfdfffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
  IO window: disabled.
  MEM window: dfc00000-dfcfffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 7, 589824 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 2819k freed
Simple Boot Flag at 0x7a set to 0x1
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
Total HugeTLB memory allocated, 0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Boot video device is 0000:00:02.0
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:01.0:pcie00]
Allocate Port Service[0000:00:01.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
Allocate Port Service[0000:00:1c.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.1:pcie00]
Allocate Port Service[0000:00:1c.1:pcie02]
Allocate Port Service[0000:00:1c.1:pcie03]
Real Time Clock Driver v1.12ac
intel_rng: Firmware space is locked read-only. If you can't or
intel_rng: don't want to disable this in firmware setup, and if
intel_rng: you are certain that your system has a functional
intel_rng: RNG, try using the 'no_fwh_detect' option.
Linux agpgart interface v0.102
agpgart: Detected an Intel E7221 (i915) Chipset.
agpgart: Detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xf0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
Copyright (c) 1999-2006 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
tg3.c:v3.87 (December 20, 2007)
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: Tigon3 [partno(BCM95751) rev 4001 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:13:20:2f:3f:b2
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76180000] dma_mask[64-bit]
console [netcon0] enabled
netconsole: network logging started
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Probing IDE interface ide0...
Clocksource tsc unstable (delta = 15005837098 ns)
Time: jiffies clocksource has been installed.
hda: HL-DT-STDVD-ROM GDR8163B, ATAPI CD/DVD-ROM drive
Probing IDE interface ide1...
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: ATAPI 48X DVD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.20
3ware Storage Controller device driver for Linux face driver usblp
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
device-mapper: ioctl: 4.12.0-ioctl (2007-10-02) initialised: dm-devel@redhat.com
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
oprofile: using NMI interrupt.
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Debug warning: early ioremap leak of 4 areas detected.
please boot with early_ioremap_debug and report the dmesg.
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:405 check_early_ioremap_leak+0x33/0x3d()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24-x86numa-06390-g7d8f371 #2
 [<c0124014>] warn_on_slowpath+0x41/0x51
 [<c0104c87>] ? restore_nocheck+0x12/0x15
 [<c0124781>] ? release_console_sem+0x1a8/0x1bb
 [<c0124c41>] ? vprintk+0x2c7/0x301
 [<c013d0f7>] ? lock_release_holdtime+0x3f/0x44
 [<c0108dec>] ? native_sched_clock+0x8d/0x9f
 [<c03e30c2>] ? _spin_unlock_irqrestore+0x36/0x3c
 [<c013eb23>] ? trace_hardirqs_on+0xe1/0x102
 [<c0124c90>] ? printk+0x15/0x17
 [<c058245b>] check_early_ioremap_leak+0x33/0x3d
 [<c057449f>] kernel_init+0x147/0x291
 [<c0574358>] ? kernel_init+0x0/0x291
 [<c0574358>] ? kernel_init+0x0/0x291
 [<c01058af>] kernel_thread_helper+0x7/0x10
 =======================
---[ end trace ca143223eefdc828 ]---
Using IPI No-Shortcut mode
registered taskstats version 1
Freeing unused kernel memory: 580k freed
Red Hat nash version 5.1.19.6 starting
USB Universal Host Controller Interface driver v3.0
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 21, io base 0x0000ff80
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 22, io base 0x0000ff60
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000ff40
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.3: irq 23, io base 0x0000ff20
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 21, io mem 0xffa80800
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
libata version 3.00 loaded.
ahci 0000:00:1f.2: version 3.0
usb 5-8: new high speed USB device using ehci_hcd and address 2
usb 5-8: configuration #1 chosen from 1 choice
ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl IDE mode
ahci 0000:00:1f.2: flags: 64bit ncq pm led slum part
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 abar m1024@0xdff3fc00 port 0xdff3fd00 irq 20
ata2: SATA max UDMA/133 abar m1024@0xdff3fc00 port 0xdff3fd80 irq 20
ata3: SATA max UDMA/133 abar m1024@0xdff3fc00 port 0xdff3fe00 irq 20
ata4: SATA max UDMA/133 abar m1024@0xdff3fc00 port 0xdff3fe80 irq 20
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-6: WDC WD800JD-75JNC0, 06.01C06, max UDMA/100
ata1.00: 156250000 sectors, multi 8: LBA
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
ata3: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access     ATA      WDC WD800JD-75JN 06.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 156250000 512-byte hardware sectors (80000 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 156250000 512-byte hardware sectors (80000 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
ata_piix 0000:00:1f.1: version 2.12
PCI: Unable to reserve I/O region #1:8@1f0 for device 0000:00:1f.1
ata_piix 0000:00:1f.1: failed to request/iomap BARs for port 0 (errno=-16)
PCI: Setting latency timer of device 0000:00:1f.1 to 64
scsi4 : ata_piix
scsi5 : ata_piix
ata5: DUMMY
ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
ata6: port disabled. ignoring.
Initializing USB Mass Storage driver...
scsi6 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
scsi 6:0:0:0: Direct-Access     ST325082 3A               0811 PQ: 0 ANSI: 0
sd 6:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB)
sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB)
sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled
sd 6:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 6:0:0:0: [sdb] Attached SCSI disk
sd 6:0:0:0: Attached scsi generic sg1 type 0
usb-storage: device scan complete
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
  3 logical volume(s) in volume group "VolGroup00" now active
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
                Welcome to  CentOS release 5 (Final)
                Press 'I' to enter interactive startup.


[-- Attachment #5: ingo_checkout.sh --]
[-- Type: application/x-sh, Size: 1101 bytes --]