linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

      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).