Comment 11 for bug 1022561

Ok, bisection ended up with:

commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
Author: WANG Cong <email address hidden>
Date: Mon Mar 5 15:05:13 2012 -0800

    x86/mm: Fix the size calculation of mapping tables

    For machines that enable PSE, the first 2/4M memory region still uses
    4K pages, so needs more PTEs in this case, but
    find_early_table_space() doesn't count this.

And I was able to make the kdump kernel run by reverting back the size calculations to what they were before. Actually, I am quite confident that this change is wrong for the 64bit case. The calling function has some comments about the first 2/4M regions but that is all encapsulated into #ifdef CONFIG_X86_32.

With some debug output I get this on 64bit (without reverting 77e00000 would be added to extra space!):
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x77e87fff]
[ 0.000000] [mem 0x00000000-0x77dfffff] page 2M
[ 0.000000] [mem 0x77e00000-0x77e87fff] page 4k
[ 0.000000] mr->end(77e00000)-mr->start(0)=77e00000
[ 0.000000] extra is 88000
[ 0.000000] kernel direct mapping tables up to 0x77e87fff @ [mem 0x1fffc000-0x1fffffff]

So I think there is a substantial amount of space wasted and in the kdump case this again brings us into trouble of fitting the initrd+unpacked+kernel. Theoretically the 32bit case should be ok, but I must admit I never tested that on bare metal. yet.