From: james.morse@arm•com (James Morse)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] arm64: kdump: retain reserved memory regions
Date: Fri, 19 Jan 2018 11:39:58 +0000 [thread overview]
Message-ID: <5A61D90E.1000907@arm.com> (raw)
In-Reply-To: <20180111113840.GF18820@linaro.org>
Hi Akashi,
On 11/01/18 11:38, AKASHI Takahiro wrote:
> On Wed, Jan 10, 2018 at 11:26:55AM +0000, James Morse wrote:
>> On 10/01/18 10:09, AKASHI Takahiro wrote:
>>> This is a fix against the issue that crash dump kernel may hang up
>>> during booting, which can happen on any ACPI-based system with "ACPI
>>> Reclaim Memory."
>>> (diagnosis)
>>> * This fault is a data abort, alignment fault (ESR=0x96000021)
>>> during reading out ACPI table.
>>> * Initial ACPI tables are normally stored in system ram and marked as
>>> "ACPI Reclaim memory" by the firmware.
>>> * After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
>>> memory as MEMBLOCK_NOMAP"), those regions' attribute were changed
>>> removing NOMAP bit and they are instead "memblock-reserved".
>>> * When crash dump kernel boots up, it tries to accesses ACPI tables by
>>> ioremap'ing them (through acpi_os_ioremap()).
>>> * Since those regions are not included in device tree's
>>> "usable-memory-range" and so not recognized as part of crash dump
>>> kernel's system ram, ioremap() will create a non-cacheable mapping here.
>>
>> Ugh, because acpi_os_ioremap() looks at the efi memory map through the prism of
>> what we pulled into memblock, which is different during kdump.
>>
>> Is an alternative to teach acpi_os_ioremap() to ask
>> efi_mem_attributes() directly for the attributes to use?
>> (e.g. arch_apei_get_mem_attribute())
>
> I didn't think of this approach.
> Do you mean a change like the patch below?
Yes. Aha, you can pretty much re-use the helper directly.
It was just a suggestion, removing the extra abstraction that is causing the bug
could be cleaner ...
> (I'm still debugging this code since the kernel fails to boot.)
... but might be too fragile.
There are points during boot when the EFI memory map isn't mapped. I think that
helper will return 'device memory' for everything when this happens.
Thanks,
James
next prev parent reply other threads:[~2018-01-19 11:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 10:09 [PATCH] arm64: kdump: retain reserved memory regions AKASHI Takahiro
2018-01-10 11:09 ` Ard Biesheuvel
2018-01-11 11:32 ` AKASHI Takahiro
2018-01-10 11:26 ` James Morse
2018-01-11 11:38 ` AKASHI Takahiro
2018-01-19 11:39 ` James Morse [this message]
2018-01-29 8:12 ` AKASHI Takahiro
2018-01-29 12:11 ` Ard Biesheuvel
2018-01-31 5:50 ` Bhupesh Sharma
2018-01-31 6:23 ` AKASHI Takahiro
2018-01-23 1:19 ` Goel, Sameer
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=5A61D90E.1000907@arm.com \
--to=james.morse@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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