Re: x86/mm: Limit 2/4M size calculation to x86_32

[Stefan Bader]

On 07/13/2012 11:12 AM, Yinghai Lu wrote:
> On Fri, Jul 13, 2012 at 6:41 AM, Stefan Bader
> <stefan.bader@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/