From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [v2 0/5] arm64: add kdump support
Date: Fri, 24 Apr 2015 10:53:13 +0100 [thread overview]
Message-ID: <20150424095312.GD29183@leverpostej> (raw)
In-Reply-To: <1429861989-8417-1-git-send-email-takahiro.akashi@linaro.org>
Hi,
On Fri, Apr 24, 2015 at 08:53:03AM +0100, AKASHI Takahiro wrote:
> This patch set enables kdump (crash dump kernel) support on arm64 on top of
> Geoff's kexec patchset.
>
> In this version, there are some arm64-specific usage/constraints:
> 1) "mem=" boot parameter must be specified on crash dump kernel
> if the system starts on uefi.
This sounds very painful. Why is this the case, and how do x86 and/or
ia64 get around that?
> 2) Kvm will not be enabled on crash dump kernel even if configured
> See commit messages and Documentation/kdump/kdump.txt for details.
>
> The only concern I have is whether or not we can use the exact same kernel
> as both system kernel and crash dump kernel. The current arm64 kernel is
> not relocatable in the exact sense but I see no problems in using the same
> binary when testing kdump.
Ard has been working on decoupling the kernel text/data, FDT, and linear
memory mappings, which would allow the kernel to be loaded anywhere and
still be able to access all of memory [3]. I assume that's what you mean
by "relocatable"?
> I tested the code with
> - ATF v1.1 + EDK2(UEFI) v3.0-rc0
> - kernel v4.0 + Geoff' kexec v9
> on
> - Base fast model, and
> - MediaTek MT8173-EVB
> using my own kexec-tools [1], currently v0.12.
>
> You may want to start a kernel with the following boot parameter:
> crashkernel=64M (or so, on model)
> and try
> $ kexec -p --load <vmlinux> --append ...
> $ echo c > /proc/sysrq-trigger
>
> To examine vmcore (/proc/vmcore), you should use
> - gdb v7.7 or later
> - crash + a small patch (to recognize v4.0 kernel)
>
> Changes from v1:
> * rebased to Geoff's v9
> * tested this patchset on real hardware and fixed bugs:
> - added cache flush operation in ipi_cpu_stop() when shutting down
> the system. Otherwise, data saved in vmcore's note sections by
> crash_save_cpu() might not be flushed to dumped memory and crash command
> fail to fetch correct data.
We'll need to give this a go on something with a system cache too (e.g.
Seattle or X-Gene). Even if that's only UP it would give me much greater
confidence in the cache maintenance.
> I will address Mark's commit[2] after Geoff takes care of it on kexec.
> - modified to use ioremap_cache() instead of ioremap() when reading
> crash memory. Otherwise, accessing /proc/vmcore on crash dump kernel
> might cause an alignment fault.
> * allows reserve_crashkernel() to handle "crashkernel=xyz[MG]" correctly,
> thanks to Pratyush Anand. And it now also enforces memory limit.
I worry that there could be potentially bad interaction between this and
Ard's patches, depending on how the memory area to use is chosen. It is
probably fine, but we should make sure that it is.
> * moved reserve_crashkernel() and reserve_elfcorehdr() to
> arm64_memblock_init() to clarify that they should be called before
> dma_contignuous_reserve().
>
> [1] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/338171.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/337596.html
Thanks,
Mark.
next prev parent reply other threads:[~2015-04-24 9:53 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 7:53 [v2 0/5] arm64: add kdump support AKASHI Takahiro
2015-04-24 7:53 ` [v2 1/5] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2015-04-24 10:11 ` Mark Rutland
2015-05-11 6:44 ` AKASHI Takahiro
2015-04-28 9:19 ` Baoquan He
2015-05-11 7:38 ` AKASHI Takahiro
2015-05-11 7:54 ` Baoquan He
2015-05-11 8:17 ` AKASHI Takahiro
2015-05-11 9:41 ` Baoquan He
2015-05-12 7:32 ` AKASHI Takahiro
2015-04-24 7:53 ` [v2 2/5] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2015-04-24 10:39 ` Mark Rutland
2015-04-24 10:43 ` Marc Zyngier
2015-08-06 7:09 ` AKASHI Takahiro
2015-08-06 15:51 ` Marc Zyngier
2015-08-07 4:24 ` AKASHI Takahiro
2015-05-11 7:10 ` AKASHI Takahiro
2015-05-22 5:56 ` AKASHI Takahiro
2015-04-24 7:53 ` [v2 3/5] arm64: kdump: do not go into EL2 before starting a crash dump kernel AKASHI Takahiro
2015-04-24 7:53 ` [v2 4/5] arm64: add kdump support AKASHI Takahiro
2015-05-08 12:19 ` Dave Young
2015-05-11 7:47 ` Dave Young
2015-05-11 7:58 ` AKASHI Takahiro
2015-05-11 8:39 ` Dave Young
2015-04-24 7:53 ` [v2 5/5] arm64: enable kdump in the arm64 defconfig AKASHI Takahiro
2015-04-24 9:53 ` Mark Rutland [this message]
2015-05-11 6:16 ` [v2 0/5] arm64: add kdump support AKASHI Takahiro
2015-05-12 5:43 ` Dave Young
2015-05-18 8:08 ` AKASHI Takahiro
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=20150424095312.GD29183@leverpostej \
--to=mark.rutland@arm.com \
--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