On 07/13/2012 11:12 AM, Yinghai Lu wrote:
On Fri, Jul 13, 2012 at 6:41 AM, Stefan Bader
<stefan.ba...@canonical.com> wrote:
I was bisecting a problem on 64bit where any attempt to cause a crash kernel to
boot would hang. The bisect ended up on commit 722bc6b (x86/mm: Fix the size
calculation of mapping tables) and somehow, looking at the calling function and
the ranges printed on boot, I think the calculations should only be done in the
32bit case.
On 64bit:
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x77e87fff]
[ 0.000000] [mem 0x00000000-0x77dfffff] page 2M
[ 0.000000] [mem 0x77e00000-0x77e87fff] page 4k
Attached patch would fix this if you agree with it. Thanks.
it does not look like for the hang for your system. maybe just because
it change a bit memblock allocation layout.
The hang is merely the effect of limited memory getting even more limited and
running out of it while trying to uncompress your initramfs and/or kernel is not
helping.
can you please post whole boot log that is working and not?
I am traveling this week and have no access to the machine. But basically you
can see the issue relatively simple. As 64bit does not have the first 2/4M area
as 4k pages. So with the current state of the patch this would allocate extra
space of about 3MB for the first range (about 1.9GB).
Again the problem is not something bad going on beyond the fact that it wastes
memory and it just happens to be more than it used to be, so the memory set
aside for getting it to boot suddenly failed to be enough.
-Stefan
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
