From: Will Deacon <will.deacon@arm.com>
To: Wang Nan <wangnan0@huawei.com>
Cc: "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Geng Hui <hui.geng@huawei.com>, Simon Horman <horms@verge.net.au>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid
Date: Mon, 19 May 2014 17:09:48 +0100 [thread overview]
Message-ID: <20140519160947.GM15130@arm.com> (raw)
In-Reply-To: <1400464443-34816-1-git-send-email-wangnan0@huawei.com>
On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote:
> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
> the second kernel ioremap first kernel's memory if the address falls
> into second kernel section. This limitation requires the second kernel
> occupies a full section, and elfcorehdr must resides in another section.
>
> This patch makes crash dump kernel use strict pfn_valid, removes such
> limitation.
>
> For example:
>
> For a platform with SECTION_SIZE_BITS == 28 (256MiB) and
> crashkernel=128M@0x28000000 in kernel cmdline, the second
> kernel is loaded at 0x28000000. Kexec puts elfcorehdr at
> 0x2ff00000, and passes 'elfcorehdr=0x2ff00000 mem=130048K' to
> second kernel. When second kernel start, it tries to use
> ioremap to retrive its elfcorehrd. In this case, elfcodehdr is at the
> same section of the second kernel, pfn_valid will recongnize
> the page as valid, so ioremap will refuse to map it.
So isn't the issue here that you're passing an incorrect mem= parameter
to the crash kernel?
Will
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid
Date: Mon, 19 May 2014 17:09:48 +0100 [thread overview]
Message-ID: <20140519160947.GM15130@arm.com> (raw)
In-Reply-To: <1400464443-34816-1-git-send-email-wangnan0@huawei.com>
On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote:
> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
> the second kernel ioremap first kernel's memory if the address falls
> into second kernel section. This limitation requires the second kernel
> occupies a full section, and elfcorehdr must resides in another section.
>
> This patch makes crash dump kernel use strict pfn_valid, removes such
> limitation.
>
> For example:
>
> For a platform with SECTION_SIZE_BITS == 28 (256MiB) and
> crashkernel=128M at 0x28000000 in kernel cmdline, the second
> kernel is loaded at 0x28000000. Kexec puts elfcorehdr at
> 0x2ff00000, and passes 'elfcorehdr=0x2ff00000 mem=130048K' to
> second kernel. When second kernel start, it tries to use
> ioremap to retrive its elfcorehrd. In this case, elfcodehdr is at the
> same section of the second kernel, pfn_valid will recongnize
> the page as valid, so ioremap will refuse to map it.
So isn't the issue here that you're passing an incorrect mem= parameter
to the crash kernel?
Will
next prev parent reply other threads:[~2014-05-19 16:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 1:54 [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid Wang Nan
2014-05-19 1:54 ` Wang Nan
2014-05-19 16:09 ` Will Deacon [this message]
2014-05-19 16:09 ` Will Deacon
2014-05-20 3:22 ` Wang Nan
2014-05-20 3:22 ` Wang Nan
2014-05-22 1:53 ` Wang Nan
2014-05-22 1:53 ` Wang Nan
2014-05-29 4:39 ` AKASHI Takahiro
2014-05-29 4:39 ` AKASHI Takahiro
2014-05-29 10:09 ` Wang Nan
2014-05-29 10:09 ` Wang Nan
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=20140519160947.GM15130@arm.com \
--to=will.deacon@arm.com \
--cc=akpm@linux-foundation.org \
--cc=horms@verge.net.au \
--cc=hui.geng@huawei.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=wangnan0@huawei.com \
/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.