On Sun, 13 Mar, at 09:58:47PM, Matt Fleming wrote: > (Fixing Maarten's email address which I botched originally) > > On Sun, 13 Mar, at 05:09:35PM, Scott Ashcroft wrote: > > On Fri, 2016-03-11 at 11:19 +0000, Matt Fleming wrote: > > > Some machines have EFI regions in page zero (physical address > > > 0x00000000) and historically that region has been added to the e820 > > > map via trim_bios_range(), and ultimately mapped into the kernel page > > > tables. It was not mapped via efi_map_regions() as one would expect. > > > > > > Alexis reports that with the new separate EFI page tables some boot > > > services regions, such as page zero, are not mapped. This triggers an > > > oops during the SetVirtualAddressMap() runtime call. > > > > > > I'm still seeing a failure to boot even with this patch. > > > > http://www.qzxyz.com/IMG_20160313_164601.jpgSorry for the dodgy photo but the screen has almost a mirror finish. > > > > Attached is the dmesg from 4.4 with efi=debug memblock=debug > > Well, crap. Can you enable CONFIG_EFI_PGT_DUMP and send the dmesg > because it would be good to know how things are mapped before this > patch. > > I'd be surprised if the issue you're seeing is related to the one that > Alexis reported. Having corrupt page table structures is a whole new > bag of scary. > > Does $(grep pdpe1gb /proc/cpuinfo) show any output on your machine? Assuming the answer to this question is "no", can you try out this patch? diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 8fee5b6f8f66..af74849e8c0f 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -1055,7 +1055,7 @@ static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd, /* * Map everything starting from the Gb boundary, possibly with 1G pages */ - while (end - start >= PUD_SIZE) { + while (cpu_has_gbpages && end - start >= PUD_SIZE) { set_pud(pud, __pud(cpa->pfn << PAGE_SHIFT | _PAGE_PSE | massage_pgprot(pud_pgprot))); -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
