From: asamson@codeaurora.org (Azriel Samson)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM64 kexec/kdump timeline
Date: Fri, 4 Dec 2015 14:53:38 -0700 [thread overview]
Message-ID: <56620B62.5060800@codeaurora.org> (raw)
In-Reply-To: <CAB5YjtCCO3vB6hrktL9wmpSP6mmtHGd-TQhYK3GnS1eQ7-XU-w@mail.gmail.com>
Hi,
On 7/13/2015 3:03 AM, AKASHI, Takahiro wrote:
> Sorry for not replying soon.
>
> On 9 July 2015 at 08:03, Azriel Samson <asamson@codeaurora.org
> <mailto:asamson@codeaurora.org>> wrote:
> >
> > Hi,
> >
> > When booting the crash kernel with ACPI, how do you ensure that the ACPI
> > tables fall within the kernel's memmap region?
> > I was able to boot with ACPI when the crash kernel's memory overlapped
> > with the ACPI tables(based on the "crashkernel" and "mem" boot
> arguments).
>
> I don't think this is a right way to use kdump in ACPI environment on arm64
> because "mem" parameter only limits the maximum size of usable memory
> and so the crash dump data (/proc/vmcore) can get easily corrupted if
> the reserved
> memory region that the crash dump kernel can use also contains any
> portion of
> memory which belong to the crashed kernel.
>
> In the current implementation of arm64 kdump, kexec command manages to
> exclude such memory regions by modifying the device tree passed on to
> the crash dump kernel.
>
> > Is there a better way to make the ACPI tables available to the crash
> kernel?
>
> So ACPI tables is not the only problem.
> x86 seems to use "memmap" kernel parameter instead.(?)
I was able to test kdump with the following patch from Mark Salter which
is needed for supporting ACPI tables that lie outside of kernel RAM:
https://git.fedorahosted.org/cgit/kernel-arm64.git/commit/?h=devel&id=a75bcec5679a2ff82f23c5cc335c77da158a6dc5
>
> Thanks,
> -Takahiro AKASHI
>
--
Thanks,
Azriel Samson
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
prev parent reply other threads:[~2015-12-04 21:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <555E37FC.9020800@codeaurora.org>
[not found] ` <1432239334.1922.7.camel@infradead.org>
2015-05-27 3:08 ` ARM64 kexec/kdump timeline Timur Tabi
2015-05-27 9:38 ` Ard Biesheuvel
2015-05-28 3:22 ` Hanjun Guo
2015-05-28 16:49 ` Geoff Levand
2015-05-27 16:32 ` Geoff Levand
2015-05-27 16:39 ` Arnd Bergmann
2015-05-27 23:14 ` Timur Tabi
2015-05-28 3:52 ` Hanjun Guo
2015-05-28 7:16 ` Ard Biesheuvel
2015-06-01 6:25 ` Pratyush Anand
2015-06-29 23:20 ` Timur Tabi
2015-07-08 23:03 ` Azriel Samson
[not found] ` <CAB5YjtCCO3vB6hrktL9wmpSP6mmtHGd-TQhYK3GnS1eQ7-XU-w@mail.gmail.com>
2015-12-04 21:53 ` Azriel Samson [this message]
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=56620B62.5060800@codeaurora.org \
--to=asamson@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).