Skip to contentSkip to conversation

tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

PATCH In review Suresh Siddha 4 participants 16 messages Jul 8, 2008 – Jul 9, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

With out this 64bit tip/master doesn't boot using ACPI on my system.
---

max_pfn_mapped should include all e820 entries.
The direct mapping extends to max_pfn_mapped, so that we can directly access apertures, ACPI and other tables without having to play with fixmaps.

With this, my system with 1GB memory boots fine with ACPI enabled.

---

arch/x86/kernel/e820.c +10 -0
Index: tree-x86/arch/x86/kernel/e820.c
===================================================================
@@ -1040,6 +1040,10 @@
 
 	if (last_pfn > max_arch_pfn)
 		last_pfn = max_arch_pfn;
+#ifdef CONFIG_X86_64
+	if (last_pfn > max_pfn_mapped)
+		max_pfn_mapped = last_pfn;
+#endif
 	if (last_pfn > end_user_pfn)
 		last_pfn = end_user_pfn;
 
@@ -1067,6 +1071,12 @@
 	if (*ei_startpfn >= *ei_endpfn)
 		return 0;
 
+#ifdef CONFIG_X86_64
+	/* Check if max_pfn_mapped should be updated */
+	if (ei->type != E820_RAM && *ei_endpfn > max_pfn_mapped)
+		max_pfn_mapped = *ei_endpfn;
+#endif
+
 	/* Skip if map is outside the node */
 	if (ei->type != E820_RAM || *ei_endpfn <= start_pfn ||
 				    *ei_startpfn >= last_pfn)
arch/x86/kernel/setup.c +4 -0
Index: tree-x86/arch/x86/kernel/setup.c
===================================================================
@@ -722,8 +722,12 @@
 	high_memory = (void *)__va(max_pfn * PAGE_SIZE - 1) + 1;
 #endif
 
+#ifdef CONFIG_X86_32
 	/* max_pfn_mapped is updated here */
 	max_pfn_mapped = init_memory_mapping(0, (max_low_pfn << PAGE_SHIFT));
+#else
+	max_pfn_mapped = init_memory_mapping(0, (max_pfn_mapped << PAGE_SHIFT));
+#endif
 
 	/*
 	 * NOTE: On x86-32, only from this point on, fixmaps are ready for use.
#1 lore raw
Quoted 11 lines · Suresh Siddha

With out this 64bit tip/master doesn't boot using ACPI on my system.
---

max_pfn_mapped should include all e820 entries.
The direct mapping extends to max_pfn_mapped, so that we can directly access apertures, ACPI and other tables without having to play with fixmaps.

With this, my system with 1GB memory boots fine with ACPI enabled.

---

please check

[PATCH] x86: introduce page_size_mask for 64bit
http://lkml.org/lkml/2008/7/8/49
[PATCH] x86: not overmap than end in init_memory_mapping - 64bit
http://lkml.org/lkml/2008/7/8/50

with this patch, on system that support gbpages
change
last_map_addr: 1080000000 end: 1078000000
to
last_map_addr: 1078000000 end: 1078000000

/sys/kernel/debug/kernel_page_tables

0xffff881040000000-0xffff881074400000         836M     RW         PSE GLB NX pmd
0xffff881074400000-0xffff8810744b0000         704K     RW             GLB NX pte
0xffff8810744b0000-0xffff8810744c0000          64K     RW     PCD     GLB NX pte
0xffff8810744c0000-0xffff881074600000        1280K     RW             GLB NX pte
0xffff881074600000-0xffff881080000000         186M     RW         PSE

GLB NX pmd ---> wrong
0xffff881080000000-0xffff888000000000 446G pud
0xffff888000000000-0xffffc20000000000 58880G pgd
===>

0xffff881040000000-0xffff881074400000         836M     RW         PSE GLB NX pmd
0xffff881074400000-0xffff8810744a0000         640K     RW             GLB NX pte
0xffff8810744a0000-0xffff8810744b0000          64K     RW     PCD     GLB NX pte
0xffff8810744b0000-0xffff881074600000        1344K     RW             GLB NX pte
0xffff881074600000-0xffff881078000000          58M     RW         PSE GLB NX pmd
0xffff881078000000-0xffff881080000000         128M                           pmd
0xffff881080000000-0xffff888000000000         446G                           pud
0xffff888000000000-0xffffc20000000000       58880G                           pgd

YH

#2 lore raw
In reply to Suresh Siddha
Quoted 8 lines · Suresh Siddha

With out this 64bit tip/master doesn't boot using ACPI on my system.
---

max_pfn_mapped should include all e820 entries.
The direct mapping extends to max_pfn_mapped, so that we can directly access apertures, ACPI and other tables without having to play with fixmaps.

With this, my system with 1GB memory boots fine with ACPI enabled.

so without this patch, your system doesn't boot?

YH

#3 lore raw
Quoted 11 lines · Yinghai Lu
Quoted 8 lines · Suresh Siddha

With out this 64bit tip/master doesn't boot using ACPI on my system.
---

max_pfn_mapped should include all e820 entries.
The direct mapping extends to max_pfn_mapped, so that we can directly access apertures, ACPI and other tables without having to play with fixmaps.

With this, my system with 1GB memory boots fine with ACPI enabled.

so without this patch, your system doesn't boot?

how about attached patch?

[PATCH] x86: make max_pfn cover acpi table below 4g

when system have 4g less ram installed, and acpi table sit near end of ram. make max_pfn cover them too.
so 64bit kernel don't need to mess up fixmap

YH

[PATCH] x86: make max_pfn cover acpi table below 4g

when system have 4g less ram installed, and acpi table sit near end of ram. make max_pfn cover them too.
so 64bit kernel don't need to mess up fixmap.

---
 arch/x86/kernel/e820.c  |   18 ++++++++++++------
 arch/x86/kernel/setup.c |   13 +++----------
 include/asm-x86/e820.h  |    2 +-
 3 files changed, 16 insertions(+), 17 deletions(-)
arch/x86/kernel/e820.c +12 -6
Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
@@ -1056,12 +1056,20 @@ unsigned long __initdata end_user_pfn =
 /*
  * Find the highest page frame number we have available
  */
-unsigned long __init e820_end_of_ram(void)
+unsigned long __init e820_end(void)
 {
-	unsigned long last_pfn;
+	int i;
+	unsigned long last_pfn = 0;
 	unsigned long max_arch_pfn = MAX_ARCH_PFN;
 
-	last_pfn = find_max_pfn_with_active_regions();
+	for (i = 0; i < e820.nr_map; i++) {
+		struct e820entry *ei = &e820.map[i];
+		unsigned long end_pfn;
+
+		end_pfn = (ei->addr + ei->size) >> PAGE_SHIFT;
+		if (end_pfn > last_pfn)
+			last_pfn = end_pfn;
+	}
 
 	if (last_pfn > max_arch_pfn)
 		last_pfn = max_arch_pfn;
@@ -1192,9 +1200,7 @@ static int __init parse_memmap_opt(char
 		 * the real mem size before original memory map is
 		 * reset.
 		 */
-		e820_register_active_regions(0, 0, -1UL);
-		saved_max_pfn = e820_end_of_ram();
-		remove_all_active_ranges();
+		saved_max_pfn = e820_end();
 #endif
 		e820.nr_map = 0;
 		userdef = 1;
arch/x86/kernel/setup.c +3 -10
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
@@ -714,22 +714,18 @@ void __init setup_arch(char **cmdline_p)
 	early_gart_iommu_check();
 #endif
 
-	e820_register_active_regions(0, 0, -1UL);
 	/*
 	 * partially used pages are not usable - thus
 	 * we are rounding upwards:
 	 */
-	max_pfn = e820_end_of_ram();
+	max_pfn = e820_end();
 
 	/* preallocate 4k for mptable mpc */
 	early_reserve_e820_mpc_new();
 	/* update e820 for memory not covered by WB MTRRs */
 	mtrr_bp_init();
-	if (mtrr_trim_uncached_memory(max_pfn)) {
-		remove_all_active_ranges();
-		e820_register_active_regions(0, 0, -1UL);
-		max_pfn = e820_end_of_ram();
-	}
+	if (mtrr_trim_uncached_memory(max_pfn))
+		max_pfn = e820_end();
 
 #ifdef CONFIG_X86_32
 	/* max_low_pfn get updated here */
@@ -772,9 +768,6 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	acpi_boot_table_init();
 
-	/* Remove active ranges so rediscovery with NUMA-awareness happens */
-	remove_all_active_ranges();
-
 #ifdef CONFIG_ACPI_NUMA
 	/*
 	 * Parse SRAT to discover nodes.
include/asm-x86/e820.h +1 -1
Index: linux-2.6/include/asm-x86/e820.h
===================================================================
@@ -99,7 +99,7 @@ extern void free_early(u64 start, u64 en
 extern void early_res_to_bootmem(u64 start, u64 end);
 extern u64 early_reserve_e820(u64 startt, u64 sizet, u64 align);
 
-extern unsigned long e820_end_of_ram(void);
+extern unsigned long e820_end(void);
 extern int e820_find_active_region(const struct e820entry *ei,
 				  unsigned long start_pfn,
 				  unsigned long last_pfn,
#4 lore raw
Quoted 13 lines · Yinghai Lu
Quoted 11 lines · Yinghai Lu
Quoted 8 lines · Suresh Siddha

With out this 64bit tip/master doesn't boot using ACPI on my system.
---

max_pfn_mapped should include all e820 entries.
The direct mapping extends to max_pfn_mapped, so that we can directly access apertures, ACPI and other tables without having to play with fixmaps.

With this, my system with 1GB memory boots fine with ACPI enabled.

so without this patch, your system doesn't boot?

Quoted 7 lines

how about attached patch?

[PATCH] x86: make max_pfn cover acpi table below 4g

when system have 4g less ram installed, and acpi table sit near end of ram. make max_pfn cover them too.
so 64bit kernel don't need to mess up fixmap

Now the latest 64bit x86 tip/master (latest commit d1f7cb8) doesn't boot on any of my test systems :( It gets a very early exception..

I can't even revert your max_pfn patch, to see if this early exception is caused by this patch.. There seems to be more changes on top of it already overnight...

BTW, please explain the need for your patch which has more changes, instead of my simple patch which was test booted on 3 different systems with both 32bit and 64bit kernels...

thanks,
suresh

#5 lore raw
Quoted 16 lines · Suresh Siddha
Quoted 15 lines · Yinghai Lu
Quoted 11 lines · Yinghai Lu
Quoted 8 lines · Suresh Siddha

With out this 64bit tip/master doesn't boot using ACPI on my system.
---

max_pfn_mapped should include all e820 entries.
The direct mapping extends to max_pfn_mapped, so that we can directly access apertures, ACPI and other tables without having to play with fixmaps.

With this, my system with 1GB memory boots fine with ACPI enabled.

so without this patch, your system doesn't boot?

how about attached patch?

Quoted 8 lines
Quoted 5 lines

[PATCH] x86: make max_pfn cover acpi table below 4g

when system have 4g less ram installed, and acpi table sit near end of ram. make max_pfn cover them too.
so 64bit kernel don't need to mess up fixmap

Now the latest 64bit x86 tip/master (latest commit d1f7cb8) doesn't boot on any of my test systems :( It gets a very early exception..

fix one panic on Ingo's machine

Quoted 8 lines

I can't even revert your max_pfn patch, to see if this early exception is caused by this patch.. There seems to be more changes on top of it already overnight...

BTW, please explain the need for your patch which has more changes, instead of my simple patch which was test booted on 3 different systems with both 32bit and 64bit kernels...

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

could be some regression from early_io_remap unifying from jeremy

please check attached revert patch.

YH

YH

revert unifying early_io_remap

also remove the cover so make e820_end to return max ram type for 64bit.

arch/x86/kernel/e820.c +0 -2
index 66fd5bd..9836a07 100644
@@ -1066,10 +1066,8 @@ unsigned long __init e820_end(void)
 		struct e820entry *ei = &e820.map[i];
 		unsigned long end_pfn;
 
-#ifdef CONFIG_X86_32
 		if (ei->type != E820_RAM)
 			continue;
-#endif
 
 		end_pfn = (ei->addr + ei->size) >> PAGE_SHIFT;
 		if (end_pfn > last_pfn)
arch/x86/kernel/head_64.S +6 -0
index 2240f82..db3280a 100644
@@ -362,6 +362,12 @@ NEXT_PAGE(level3_kernel_pgt)
 	.quad	level2_fixmap_pgt - __START_KERNEL_map + _PAGE_TABLE
 
 NEXT_PAGE(level2_fixmap_pgt)
+	.fill	506,8,0
+	.quad	level1_fixmap_pgt - __START_KERNEL_map + _PAGE_TABLE
+	/* 8MB reserved for vsyscalls + a 2MB hole = 4 + 1 entries */
+	.fill	5,8,0
+
+NEXT_PAGE(level1_fixmap_pgt)
 	.fill	512,8,0
 
 NEXT_PAGE(level2_ident_pgt)
arch/x86/kernel/setup.c +1 -2
index d418794..149ff9a 100644
@@ -598,12 +598,11 @@ void __init setup_arch(char **cmdline_p)
 	memcpy(&boot_cpu_data, &new_cpu_data, sizeof(new_cpu_data));
 	pre_setup_arch_hook();
 	early_cpu_init();
+	early_ioremap_init();
 #else
 	printk(KERN_INFO "Command line: %s\n", boot_command_line);
 #endif
 
-	early_ioremap_init();
-
 	ROOT_DEV = old_decode_dev(boot_params.hdr.root_dev);
 	screen_info = boot_params.screen_info;
 	edid_info = boot_params.edid_info;
arch/x86/mm/init_64.c +52 -0

58 lines not on this page · raw message

arch/x86/mm/ioremap.c +4 -1
index 6a05a33..47719ec 100644
@@ -409,6 +409,8 @@ void unxlate_dev_mem_ptr(unsigned long phys, void *addr)
 	return;
 }
 
+#ifdef CONFIG_X86_32
+
 int __initdata early_ioremap_debug;
 
 static int __init early_ioremap_debug_setup(char *str)
@@ -509,7 +511,6 @@ static void __init __early_set_fixmap(enum fixed_addresses idx,
 		return;
 	}
 	pte = early_ioremap_pte(addr);
-
 	if (pgprot_val(flags))
 		set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags));
 	else
@@ -649,3 +650,5 @@ void __this_fixmap_does_not_exist(void)
 {
 	WARN_ON(1);
 }
+
+#endif /* CONFIG_X86_32 */
include/asm-x86/fixmap_64.h +0 -13
index 1a0b61e..7594346 100644
@@ -52,19 +52,6 @@ enum fixed_addresses {
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
 	FIX_OHCI1394_BASE,
 #endif
-	__end_of_permanent_fixed_addresses,
-	/*
-	 * 256 temporary boot-time mappings, used by early_ioremap(),
-	 * before ioremap() is functional.
-	 *
-	 * We round it up to the next 512 pages boundary so that we
-	 * can have a single pgd entry and a single pte table:
-	 */
-#define NR_FIX_BTMAPS		64
-#define FIX_BTMAPS_NESTING	4
-	FIX_BTMAP_END = __end_of_permanent_fixed_addresses + 512 -
-			(__end_of_permanent_fixed_addresses & 511),
-	FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS*FIX_BTMAPS_NESTING - 1,
 	__end_of_fixed_addresses
 };
 
include/asm-x86/io.h +0 -13
index bf5d629..00e5f1e 100644
@@ -86,17 +86,4 @@ extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
 				unsigned long prot_val);
 extern void __iomem *ioremap_wc(unsigned long offset, unsigned long size);
 
-/*
- * early_ioremap() and early_iounmap() are for temporary early boot-time
- * mappings, before the real ioremap() is functional.
- * A boot-time mapping is currently limited to at most 16 pages.
- */
-extern void early_ioremap_init(void);
-extern void early_ioremap_clear(void);
-extern void early_ioremap_reset(void);
-extern void *early_ioremap(unsigned long offset, unsigned long size);
-extern void early_iounmap(void *addr, unsigned long size);
-extern void __iomem *fix_ioremap(unsigned idx, unsigned long phys);
-
-
 #endif /* _ASM_X86_IO_H */
include/asm-x86/io_32.h +12 -0
index 4df44ed..d71be8d 100644
@@ -122,6 +122,18 @@ static inline void __iomem *ioremap(resource_size_t offset, unsigned long size)
 extern void iounmap(volatile void __iomem *addr);
 
 /*
+ * early_ioremap() and early_iounmap() are for temporary early boot-time
+ * mappings, before the real ioremap() is functional.
+ * A boot-time mapping is currently limited to at most 16 pages.
+ */
+extern void early_ioremap_init(void);
+extern void early_ioremap_clear(void);
+extern void early_ioremap_reset(void);
+extern void *early_ioremap(unsigned long offset, unsigned long size);
+extern void early_iounmap(void *addr, unsigned long size);
+extern void __iomem *fix_ioremap(unsigned idx, unsigned long phys);
+
+/*
  * ISA I/O bus memory addresses are 1:1 with the physical address.
  */
 #define isa_virt_to_bus virt_to_phys
#6 lore raw
Quoted 5 lines · Yinghai Lu

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

could be some regression from early_io_remap unifying from jeremy

please check attached revert patch.

Could my patch "x86_64: there's no need to preallocate level1_fixmap_pgt" be a problem in itself? It seems sound to me, but none of my other code has any functional dependency on it; it's really just cosmetic.

The unified early_ioremap patch has been kicking around in tip.git for a week or more now, and doesn't seem to have caused any problems.

J

#7 lore raw
Quoted 9 lines · Jeremy Fitzhardinge
Quoted 5 lines · Yinghai Lu

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

could be some regression from early_io_remap unifying from jeremy

please check attached revert patch.

Could my patch "x86_64: there's no need to preallocate level1_fixmap_pgt" be a problem in itself? It seems sound to me, but

Yep. Reverting it made my system with 2GB memory boot fine again.

Quoted 2 lines

none of my other code has any functional dependency on it; it's really just cosmetic.

have you test booted it before making this cosmetic change? :)

thanks,
suresh

#8 lore raw
Quoted 4 lines · Suresh Siddha
Quoted 3 lines · Jeremy Fitzhardinge
Quoted 2 lines · Yinghai Lu

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

could be some regression from early_io_remap unifying from jeremy

please check attached revert patch.

Could my patch "x86_64: there's no need to preallocate level1_fixmap_pgt" be a problem in itself? It seems sound to me, but

Yep. Reverting it made my system with 2GB memory boot fine again.

only revert that one, or using the big revert patch i sent out.

Quoted 5 lines
Quoted 3 lines

none of my other code has any functional dependency on it; it's really just cosmetic.

have you test booted it before making this cosmetic change? :)

he should test system with 4g more RAM

YH

#9 lore raw
Quoted 8 lines · Yinghai Lu
Quoted 6 lines · Suresh Siddha
Quoted 5 lines · Jeremy Fitzhardinge
Quoted 4 lines · Yinghai Lu

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

could be some regression from early_io_remap unifying from jeremy

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line

please check attached revert patch.

Could my patch "x86_64: there's no need to preallocate level1_fixmap_pgt" be a problem in itself? It seems sound to me, but

Yep. Reverting it made my system with 2GB memory boot fine again.

only revert that one, or using the big revert patch i sent out.

I reverted just the "x86_64: there's no need to preallocate level1_fixmap_pgt"

#10 lore raw
Quoted 11 lines · Suresh Siddha
Quoted 10 lines · Yinghai Lu
Quoted 8 lines · Suresh Siddha
Quoted 7 lines · Jeremy Fitzhardinge
Quoted 5 lines · Yinghai Lu

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

could be some regression from early_io_remap unifying from jeremy

please check attached revert patch.

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

Could my patch "x86_64: there's no need to preallocate level1_fixmap_pgt" be a problem in itself? It seems sound to me, but

Yep. Reverting it made my system with 2GB memory boot fine again.

only revert that one, or using the big revert patch i sent out.

I reverted just the "x86_64: there's no need to preallocate level1_fixmap_pgt"

can you try to remove
#ifdef CONFIG_X86_32

that will make e820_end return end_of_ram again...

YH

#11 lore raw
In reply to Suresh Siddha
Quoted 8 lines · Suresh Siddha
Quoted 6 lines · Jeremy Fitzhardinge
Quoted 4 lines · Yinghai Lu

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

could be some regression from early_io_remap unifying from jeremy

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

please check attached revert patch.

Could my patch "x86_64: there's no need to preallocate level1_fixmap_pgt" be a problem in itself? It seems sound to me, but

Yep. Reverting it made my system with 2GB memory boot fine again.

Great. Ingo, would you do the honours of shooting that patch?

Quoted 7 lines
Quoted 3 lines

none of my other code has any functional dependency on it; it's really just cosmetic.

have you test booted it before making this cosmetic change? :)

Sure, works for me ;)

J

#12 lore raw
Quoted 7 lines · Jeremy Fitzhardinge
Quoted 5 lines
Quoted 3 lines

level1_fixmap_pgt" be a problem in itself? It seems sound to me, but

Yep. Reverting it made my system with 2GB memory boot fine again.

Great. Ingo, would you do the honours of shooting that patch?

done, i've applied the revert below.

Ingo

----------->
commit 8e48d49043b716d2331facba9ecf0b34936ee8ea

Author: Ingo Molnar <[email protected]>
Date:   Wed Jul 9 22:32:33 2008 +0200

Revert "x86_64: there's no need to preallocate level1_fixmap_pgt"

This reverts commit 033786969d1d1b5af12a32a19d3a760314d05329.

Suresh Siddha reported that this broke booting on his 2GB testbox.

arch/x86/kernel/head_64.S +6 -0
index 2240f82..db3280a 100644
@@ -362,6 +362,12 @@ NEXT_PAGE(level3_kernel_pgt)
 	.quad	level2_fixmap_pgt - __START_KERNEL_map + _PAGE_TABLE
 
 NEXT_PAGE(level2_fixmap_pgt)
+	.fill	506,8,0
+	.quad	level1_fixmap_pgt - __START_KERNEL_map + _PAGE_TABLE
+	/* 8MB reserved for vsyscalls + a 2MB hole = 4 + 1 entries */
+	.fill	5,8,0
+
+NEXT_PAGE(level1_fixmap_pgt)
 	.fill	512,8,0
 
 NEXT_PAGE(level2_ident_pgt)
#13 lore raw
In reply to Yinghai Lu
Quoted 5 lines · Yinghai Lu
Quoted 3 lines

BTW, please explain the need for your patch which has more changes, instead of my simple patch which was test booted on 3 different systems with both 32bit and 64bit kernels...

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

But it seem to have too many changes included in one patch.

like calls to e820_register_active_regions(), remove_all_active_ranges() disappeared all together in this patch.. ??

thanks,
suresh

#14 lore raw
Quoted 11 lines · Suresh Siddha
Quoted 5 lines · Yinghai Lu
Quoted 3 lines

BTW, please explain the need for your patch which has more changes, instead of my simple patch which was test booted on 3 different systems with both 32bit and 64bit kernels...

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

But it seem to have too many changes included in one patch.

like calls to e820_register_active_regions(), remove_all_active_ranges() disappeared all together in this patch.. ??

old e820_end_of_ram() need to active_ranges aka early_node_map is initialized... so if we make e820_end to get end of any type, we don't need to call e820_register_active_regions anymore. and just letnuma code init that later. to avoid extra operation.

should put more words in commit desc.

YH

#15 lore raw
In reply to Yinghai Lu
Quoted 11 lines · Yinghai Lu
Quoted 8 lines · Suresh Siddha

With out this 64bit tip/master doesn't boot using ACPI on my system.
---

max_pfn_mapped should include all e820 entries.
The direct mapping extends to max_pfn_mapped, so that we can directly access apertures, ACPI and other tables without having to play with fixmaps.

With this, my system with 1GB memory boots fine with ACPI enabled.

so without this patch, your system doesn't boot?

It doesn't enable ACPI and hence doesn't bringup SMP etc etc..