From: Stefan Bader <stefan.bader@canonical.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, WANG Cong <xiyou.wangcong@gmail.com>,
Tejun Heo <tj@kernel.org>
Subject: Re: x86/mm: Limit 2/4M size calculation to x86_32
Date: Sun, 15 Jul 2012 12:09:31 -0700 [thread overview]
Message-ID: <5003156B.2090301@canonical.com> (raw)
In-Reply-To: <CAE9FiQUxRyVLu-sgrQ-GtRye=CqGHcf9=WA-omz1s5GrxofrJg@mail.gmail.com>
On 07/13/2012 11:12 AM, Yinghai Lu wrote:
> On Fri, Jul 13, 2012 at 6:41 AM, Stefan Bader
> <stefan.bader@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
>
next prev parent reply other threads:[~2012-07-15 19:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-13 13:41 x86/mm: Limit 2/4M size calculation to x86_32 Stefan Bader
2012-07-13 18:12 ` Yinghai Lu
2012-07-15 19:09 ` Stefan Bader [this message]
2012-07-19 16:28 ` Stefan Bader
2012-07-24 15:52 ` Cong Wang
2012-07-25 10:44 ` Avi Kivity
2012-07-25 11:14 ` Stefan Bader
2012-07-25 12:32 ` Avi Kivity
2012-07-25 13:24 ` Stefan Bader
2012-07-25 13:40 ` Avi Kivity
2012-07-31 9:48 ` Stefan Bader
2012-07-31 10:07 ` Avi Kivity
2012-08-31 16:31 ` [PATCH] " Stefan Bader
2012-08-31 16:41 ` H. Peter Anvin
2012-08-31 16:56 ` Stefan Bader
2012-09-07 11:12 ` Stefan Bader
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5003156B.2090301@canonical.com \
--to=stefan.bader@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tj@kernel.org \
--cc=xiyou.wangcong@gmail.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.