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." <kicking off kdump after panic> Bye! (snip...) ACPI: Core revision 20170728 pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707 Internal error: Oops: 96000021 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1 task: ffff000008d05180 task.stack: ffff000008cc0000 PC is at acpi_ns_lookup+0x25c/0x3c0 LR is at acpi_ds_load1_begin_op+0xa4/0x294 (snip...) Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000) Call trace: (snip...) [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0 [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294 [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198 [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270 [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8 [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8 [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184 [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68 [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264 [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0 [<ffff000008badc20>] acpi_early_init+0x9c/0xd0 [<ffff000008b70d50>] start_kernel+0x3b4/0x43c Code: b9008fb9 2a000318 36380054 32190318 (b94002c0) ---[ end trace c46ed37f9651c58e ]--- Kernel panic - not syncing: Fatal exception Rebooting in 10 seconds.. (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. * ACPI accessor/helper functions are compiled in without unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED), eventually ending up a fatal panic when accessing ACPI tables. With this patch, all the reserved memory regions, as well as NOMAP- attributed ones which are presumably ACPI runtime code and data, are set to be retained in system ram even if they are outside of usable memory range specified by device tree blob. Accordingly, ACPI tables are mapped as cacheable and can be safely accessed without causing unaligned access faults. Reported-by: Bhupesh Sharma <bhsharma@xxxxxxxxxx> Signed-off-by: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx> --- arch/arm64/mm/init.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 2d5a443b205c..e4a8b64a09b1 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -352,11 +352,23 @@ static void __init fdt_enforce_memory_region(void) struct memblock_region reg = { .size = 0, }; + u64 idx; + phys_addr_t start, end; of_scan_flat_dt(early_init_dt_scan_usablemem, ®); - if (reg.size) - memblock_cap_memory_range(reg.base, reg.size); + if (reg.size) { +retry: + /* exclude usable & !reserved memory */ + for_each_free_mem_range(idx, NUMA_NO_NODE, MEMBLOCK_NONE, + &start, &end, NULL) { + memblock_remove(start, end - start); + goto retry; + } + + /* add back fdt's usable memory */ + memblock_add(reg.base, reg.size); + } } void __init arm64_memblock_init(void) -- 2.15.1 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec