tip/x86_64: fix e820 merge issue which broke max_pfn_mapped
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
@@ -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
@@ -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.
Quoted 11 lines · Suresh Siddha
With out this 64bit tip/master doesn't boot using ACPI on my system.
---
max_pfn_mappedshould include all e820 entries.
The direct mapping extends tomax_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 <[email protected]>---
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
changelast_map_addr: 1080000000 end: 1078000000
tolast_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
Quoted 8 lines · Suresh Siddha
With out this 64bit tip/master doesn't boot using ACPI on my system.
---
max_pfn_mappedshould include all e820 entries.
The direct mapping extends tomax_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
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_mappedshould include all e820 entries.
The direct mapping extends tomax_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
@@ -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
@@ -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
@@ -99,7 +99,7 @@ extern void free_early(u64 start, u64 enextern 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,
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_mappedshould include all e820 entries.
The direct mapping extends tomax_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_pfncover acpi table below 4gwhen system have 4g less ram installed, and acpi table sit near end of ram. make
max_pfncover 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
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_mappedshould include all e820 entries.
The direct mapping extends tomax_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_pfncover acpi table below 4gwhen system have 4g less ram installed, and acpi table sit near end of ram. make
max_pfncover them too.
so 64bit kernel don't need to mess up fixmapNow 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_pfnpatch, 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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_remapunifying from jeremyplease 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
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_remapunifying from jeremyplease check attached revert patch.
Could my patch "
x86_64: there's no need to preallocatelevel1_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
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_remapunifying from jeremyplease check attached revert patch.
Could my patch "
x86_64: there's no need to preallocatelevel1_fixmap_pgt" be a problem in itself? It seems sound to me, butYep. 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
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_remapunifying 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 preallocatelevel1_fixmap_pgt" be a problem in itself? It seems sound to me, butYep. 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"
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_remapunifying from jeremyplease 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 preallocatelevel1_fixmap_pgt" be a problem in itself? It seems sound to me, butYep. 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 preallocatelevel1_fixmap_pgt"
can you try to remove
#ifdef CONFIG_X86_32
that will make e820_end return end_of_ram again...
YH
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_remapunifying 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 preallocatelevel1_fixmap_pgt" be a problem in itself? It seems sound to me, butYep. 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
Quoted 7 lines · Jeremy Fitzhardinge
Quoted 5 lines
Quoted 3 lines
level1_fixmap_pgt" be a problem in itself? It seems sound to me, butYep. 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
@@ -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)
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
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
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_mappedshould include all e820 entries.
The direct mapping extends tomax_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..