On 2012.12.16 at 12:43 +0000, Matt Fleming wrote: > On Sat, 2012-12-15 at 17:35 +0100, Markus Trippelsdorf wrote: > > On 2012.12.15 at 17:33 +0100, Markus Trippelsdorf wrote: > > > On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote: > > > > On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds > > > > wrote: > > > > > I was wrong. It's not the x86 UAPI split, it's the DT pull. More people added. > > > > > > > > Looking at the merge (just in case it could have done something odd), > > > > I'm starting to worry that this is some nasty heisenbug, and my > > > > bisection is not trustworthy at all. Because the DT pull sure as heck > > > > doesn't look like a likely candidate for anything either. > > > > > > > > Ho humm. Anybody else see anything strange? > > > > > > Yes. I'm seeing a BUG early during boot on my machine (RIP=NULL): > > > > > > BUG: unable to handle kernel NULL pointer dereference at (null) > > > > > > This is caused by: > > > > > > commit 53b87cf088e2ea68d7c59619d0214cc15bb76133 > > > Author: Matt Fleming > > > Date: Fri Sep 7 18:23:51 2012 +0100 > > > > > > x86, mm: Include the entire kernel memory map in trampoline_pgd > > > > > > There are various pieces of code in arch/x86 that require a page table > > > with an identity mapping. Make trampoline_pgd a proper kernel page > > > table, it currently only includes the kernel text and module space > > > mapping. > > > > > > One new feature of trampoline_pgd is that it now has mappings for the > > > physical I/O device addresses, which are inserted at ioremap() > > > time. Some broken implementations of EFI firmware require these > > > mappings to always be around. > > > > > > Acked-by: Jan Beulich > > > Signed-off-by: Matt Fleming > > > > > > > Adding Matt to CC. > > Markus, could you please send me your full dmesg, or if possible the > dmesgs from both a working and non-working kernel. > > After looking at your memory map layout, nothing immediately jumps out. > > Could you try this revised patch and see if things work better? It's the > only thing I noticed that looked wrong with the original patch (apart > from the >512G ram bug that Yinghai pointed out). Matt, your patch fixes the problem for me. Thanks. -- Markus