[patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[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.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---

Index: tree-x86/arch/x86/kernel/e820.c
===================================================================
--- tree-x86.orig/arch/x86/kernel/e820.c	2008-07-08 15:31:24.000000000 -0700
+++ tree-x86/arch/x86/kernel/e820.c	2008-07-08 15:55:09.000000000 -0700
@@ -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)
Index: tree-x86/arch/x86/kernel/setup.c
===================================================================
--- tree-x86.orig/arch/x86/kernel/setup.c	2008-07-08 15:33:42.000000000 -0700
+++ tree-x86/arch/x86/kernel/setup.c	2008-07-08 15:33:49.000000000 -0700
@@ -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.

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Yinghai Lu]

On Tue, Jul 8, 2008 at 4:08 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> 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.
>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> ---

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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Yinghai Lu]

On Tue, Jul 8, 2008 at 4:08 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> 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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Yinghai Lu]

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

On Tue, Jul 8, 2008 at 5:59 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Tue, Jul 8, 2008 at 4:08 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
>> 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

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: e820_end.patch --]
[-- Type: text/x-patch; name=e820_end.patch, Size: 3356 bytes --]

[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.

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 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(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ 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;
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ 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.
Index: linux-2.6/include/asm-x86/e820.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820.h
+++ 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,

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Suresh Siddha]

On Tue, Jul 08, 2008 at 06:56:38PM -0700, Yinghai Lu wrote:
> On Tue, Jul 8, 2008 at 5:59 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> > On Tue, Jul 8, 2008 at 4:08 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> >> 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

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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Yinghai Lu]

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

On Wed, Jul 9, 2008 at 10:56 AM, Suresh Siddha
<suresh.b.siddha@intel.com> wrote:
> On Tue, Jul 08, 2008 at 06:56:38PM -0700, Yinghai Lu wrote:
>> On Tue, Jul 8, 2008 at 5:59 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>> > On Tue, Jul 8, 2008 at 4:08 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
>> >> 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
>
> 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

>
> 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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: revert_unify_early_ioremap.patch --]
[-- Type: text/x-patch; name=revert_unify_early_ioremap.patch, Size: 6649 bytes --]

revert unifying early_io_remap

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


diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 66fd5bd..9836a07 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -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)
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 2240f82..db3280a 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -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)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d418794..149ff9a 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -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;
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 246a2b2..70187fa 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -339,6 +339,58 @@ phys_pte_update(pmd_t *pmd, unsigned long address, unsigned long end)
 	phys_pte_init(pte, address, end);
 }
 
+/* Must run before zap_low_mappings */
+__meminit void *early_ioremap(unsigned long addr, unsigned long size)
+{
+	pmd_t *pmd, *last_pmd;
+	unsigned long vaddr;
+	int i, pmds;
+
+	pmds = ((addr & ~PMD_MASK) + size + ~PMD_MASK) / PMD_SIZE;
+	vaddr = __START_KERNEL_map;
+	pmd = level2_kernel_pgt;
+	last_pmd = level2_kernel_pgt + PTRS_PER_PMD - 1;
+
+	for (; pmd <= last_pmd; pmd++, vaddr += PMD_SIZE) {
+		for (i = 0; i < pmds; i++) {
+			if (pmd_present(pmd[i]))
+				goto continue_outer_loop;
+		}
+		vaddr += addr & ~PMD_MASK;
+		addr &= PMD_MASK;
+
+		for (i = 0; i < pmds; i++, addr += PMD_SIZE)
+			set_pmd(pmd+i, __pmd(addr | __PAGE_KERNEL_LARGE_EXEC));
+		__flush_tlb_all();
+
+		return (void *)vaddr;
+continue_outer_loop:
+		;
+	}
+	printk(KERN_ERR "early_ioremap(0x%lx, %lu) failed\n", addr, size);
+
+	return NULL;
+}
+
+/*
+ * To avoid virtual aliases later:
+ */
+__meminit void early_iounmap(void *addr, unsigned long size)
+{
+	unsigned long vaddr;
+	pmd_t *pmd;
+	int i, pmds;
+
+	vaddr = (unsigned long)addr;
+	pmds = ((vaddr & ~PMD_MASK) + size + ~PMD_MASK) / PMD_SIZE;
+	pmd = level2_kernel_pgt + pmd_index(vaddr);
+
+	for (i = 0; i < pmds; i++)
+		pmd_clear(pmd + i);
+
+	__flush_tlb_all();
+}
+
 static unsigned long __meminit
 phys_pmd_init(pmd_t *pmd_page, unsigned long address, unsigned long end,
 			 unsigned long page_size_mask)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 6a05a33..47719ec 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -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 */
diff --git a/include/asm-x86/fixmap_64.h b/include/asm-x86/fixmap_64.h
index 1a0b61e..7594346 100644
--- a/include/asm-x86/fixmap_64.h
+++ b/include/asm-x86/fixmap_64.h
@@ -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
 };
 
diff --git a/include/asm-x86/io.h b/include/asm-x86/io.h
index bf5d629..00e5f1e 100644
--- a/include/asm-x86/io.h
+++ b/include/asm-x86/io.h
@@ -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 */
diff --git a/include/asm-x86/io_32.h b/include/asm-x86/io_32.h
index 4df44ed..d71be8d 100644
--- a/include/asm-x86/io_32.h
+++ b/include/asm-x86/io_32.h
@@ -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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Jeremy Fitzhardinge]

Yinghai Lu wrote:
> 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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Suresh Siddha]

On Wed, Jul 09, 2008 at 11:11:36AM -0700, Jeremy Fitzhardinge wrote:
> Yinghai Lu wrote:
> > 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.

> 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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Yinghai Lu]

On Wed, Jul 9, 2008 at 11:44 AM, Suresh Siddha
<suresh.b.siddha@intel.com> wrote:
> On Wed, Jul 09, 2008 at 11:11:36AM -0700, Jeremy Fitzhardinge wrote:
>> Yinghai Lu wrote:
>> > 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.

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

>
>> 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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Suresh Siddha]

On Wed, Jul 09, 2008 at 11:47:38AM -0700, Yinghai Lu wrote:
> On Wed, Jul 9, 2008 at 11:44 AM, Suresh Siddha
> <suresh.b.siddha@intel.com> wrote:
> > On Wed, Jul 09, 2008 at 11:11:36AM -0700, Jeremy Fitzhardinge wrote:
> >> Yinghai Lu wrote:
> >> > 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.
> 
> 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"

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Yinghai Lu]

On Wed, Jul 9, 2008 at 11:50 AM, Suresh Siddha
<suresh.b.siddha@intel.com> wrote:
> On Wed, Jul 09, 2008 at 11:47:38AM -0700, Yinghai Lu wrote:
>> On Wed, Jul 9, 2008 at 11:44 AM, Suresh Siddha
>> <suresh.b.siddha@intel.com> wrote:
>> > On Wed, Jul 09, 2008 at 11:11:36AM -0700, Jeremy Fitzhardinge wrote:
>> >> Yinghai Lu wrote:
>> >> > 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.
>>
>> 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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Jeremy Fitzhardinge]

Suresh Siddha wrote:
> On Wed, Jul 09, 2008 at 11:11:36AM -0700, Jeremy Fitzhardinge wrote:
>   
>> Yinghai Lu wrote:
>>     
>>> 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.
>   

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

>> 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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Ingo Molnar]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

>>> 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 <mingo@elte.hu>
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.
    
    Reported-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 2240f82..db3280a 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -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)

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Suresh Siddha]

On Wed, Jul 09, 2008 at 11:05:46AM -0700, Yinghai Lu wrote:
> > 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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Yinghai Lu]

On Wed, Jul 9, 2008 at 11:48 AM, Suresh Siddha
<suresh.b.siddha@intel.com> wrote:
> On Wed, Jul 09, 2008 at 11:05:46AM -0700, Yinghai Lu wrote:
>> > 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

Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

[Suresh Siddha]

On Tue, Jul 08, 2008 at 05:59:39PM -0700, Yinghai Lu wrote:
> On Tue, Jul 8, 2008 at 4:08 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> > 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..