On Thu, Mar 8, 2012 at 3:28 AM, Matt Fleming <matt.fleming@xxxxxxxxx> wrote: > On Wed, 2012-03-07 at 10:05 -0800, Yinghai Lu wrote: >> > - >> > - max_low_pfn_mapped = init_memory_mapping(0, end_pfn << PAGE_SHIFT); >> > - max_pfn_mapped = max_low_pfn_mapped; >> > + /* max_low_pfn_mapped is updated here */ >> > + max_pfn_mapped = init_memory_mapping(); >> > >> > #ifdef CONFIG_X86_64 >> > if (max_pfn > max_low_pfn) { >> > - max_pfn_mapped = init_memory_mapping(1UL<<32, >> > - max_pfn<<PAGE_SHIFT); >> > /* can we preseve max_low_pfn ?*/ >> > max_low_pfn = max_pfn; >> > } >> >> you may need to move those three lines before >> max_pfn_mapped = init_memory_mapping() >> >> otherwise for x86_64, memory from [4G, TOMH) will not be directly mapped. > > I'm afraid I don't understand what you mean. The changes in my patch > mean that init_memory_mapping() doesn't work the way it previously did. > It will map all the regions in the e820 table and presumably the top of > memory is contained within one of those regions. > > Could you clarify what you think the problem is? Unfortunately I don't > have a test machine with large amounts of RAM so it's entirely possible > I've made a mistake somewhere. in your new init_memory_mapping will only map memory below max_low_pfn. but the max_low_pfn is under 4g. So it will be ended up with 4G above memory is not mapped. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html