On Mon, 2014-11-10 at 08:31 +0100, Ard Biesheuvel wrote: > On 10 November 2014 05:11, Mark Salter <msalter@xxxxxxxxxx> wrote: > > On Thu, 2014-11-06 at 15:13 +0100, Ard Biesheuvel wrote: > >> This changes the way memblocks are installed based on the contents > of > >> the UEFI memory map. Formerly, all regions would be > memblock_add()'ed, > >> after which unusable regions would be memblock_reserve()'d as well. > >> To simplify things, but also to allow access to the unusable > regions > >> through mmap(/dev/mem), even with CONFIG_STRICT_DEVMEM set, change > >> this so that only usable regions are memblock_add()'ed in the first > >> place. > > > > This patch is crashing 64K pagesize kernels during boot. I'm not > exactly > > sure why, though. Here is what I get on an APM Mustang box: > > > > Ah, yes, I meant to mention this patch > > https://git.kernel.org/cgit/linux/kernel/git/glikely/linux.git/commit/?id=8cccffc52694938fc88f3d90bc7fed8460e27191 > > in the cover letter, which addresses this issue at least for the DT > case. > That isn't the problem. In general, with 64K kernel pages, you can't be sure if you leave something you need out of the kernel linear mapping. If you have Loader Code/Data regions begin and/or end at something other than a 64K boundary and that region is adjacent to a region not being added, then you end up leaving out the unaligned bits from the linear mapping. This could be bits of the initramfs or devicetree. What I don't get with this failure is that it is an alignment fault which should be masked at EL1 for the kernel. The same unaligned access happens without this patch and it doesn't generate a fault. -- 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
