Resent with Akashi's correct email address. On Fri, Nov 10, 2017 at 5:39 PM, Bhupesh Sharma <bhsharma@xxxxxxxxxx> wrote: > Hi Ard, Akashi > > I have met an issue on an arm64 board using the latest master branch from Linus. > > I think I have a dirty hack to avoid the issue, but would want more > opinions from you as it might break crashkernel dump on other arm64 > machines. > > 1. This arm64 machine supports acpi only boot mode (i.e. acpi=force is > always set in bootargs) > > 2. Since f56ab9a5b73ca2aee777ccdf2d355ae2dd31db5a (efi/arm: Don't mark > ACPI reclaim memory as MEMBLOCK_NOMAP), Ard rightly added a chunk > which marks the 'EFI_ACPI_RECLAIM_MEMORY' regions as useable memory > (by setting the EFI_MEMORY_WB flag for such efi memory descriptors > thus marking them as System RAM). > > 3. However this causes crashkernel booting on ACPI only machines to fail: > > [ 0.039205] ACPI: Core revision 20170728 > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707 > [ 0.095098] Internal error: Oops: 96000021 [#1] SMP > [ 0.100022] Modules linked in: > [ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1 > [ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000 > [ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0 > [ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294 > [ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>] > pstate: 60000045 > [ 0.132647] sp : ffff000008ccfb40 > [ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4 > [ 0.141354] x27: ffff0000088be820 x26: 0000000000000000 > [ 0.146718] x25: 000000000000001b x24: 0000000000000001 > [ 0.152083] x23: 0000000000000001 x22: ffff000009710027 > [ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001 > [ 0.162812] x19: 000000000000001b x18: 0000000000000005 > [ 0.168176] x17: 0000000000000000 x16: 0000000000000000 > [ 0.173541] x15: 0000000000000000 x14: 000000000000038e > [ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff > [ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76 > [ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140 > [ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50 > [ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001 > [ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980 > [ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000 > [ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000) > [ 0.223224] Call trace: > [ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40) > [ 0.232194] fa00: 0000000000000000 ffff000009710027 > ffff0000095e3980 ffff000008ccfbe0 > [ 0.240106] fa20: 0000000000000001 ffff80000fe62c00 > ffff000008ccfc50 0000000000000000 > [ 0.248018] fa40: ffff8000126d0140 000000000000005f > 00000000ffffff76 0000000000000006 > [ 0.255931] fa60: ffffffffffffffff ffffffff00000000 > 000000000000038e 0000000000000000 > [ 0.263843] fa80: 0000000000000000 0000000000000000 > 0000000000000005 000000000000001b > [ 0.271754] faa0: 0000000000000001 ffff000008ccfc50 > ffff000009710027 0000000000000001 > [ 0.279667] fac0: 0000000000000001 000000000000001b > 0000000000000000 ffff0000088be820 > [ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40 > ffff00000849b4f8 ffff000008ccfb40 > [ 0.295491] fb00: ffff0000084a6764 0000000060000045 > ffff000008ccfb40 ffff000008260a18 > [ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0 > ffff000008ccfb40 ffff0000084a6764 > [ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0 > [ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294 > [ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198 > [ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270 > [ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8 > [ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8 > [ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184 > [ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68 > [ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc > [ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264 > [ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0 > [ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0 > [ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c > [ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0) > [ 0.394500] ---[ end trace c46ed37f9651c58e ]--- > [ 0.399160] Kernel panic - not syncing: Fatal exception > [ 0.404437] Rebooting in 10 seconds.. > > 4. On the primary kernel boot, I notice with efi=debug that while the > ACPI regions are properly recognized as Reclaim regions: > > ... > [ 0.000000] efi: 0x000039710000-0x00003975ffff [ACPI Reclaim > Memory| | | | | | | | |WB|WT|WC|UC] > [ 0.000000] efi: 0x000039770000-0x0000397affff [ACPI Reclaim > Memory| | | | | | | | |WB|WT|WC|UC] > ... > [ 0.000000] efi: 0x0000398a0000-0x0000398bffff [ACPI Reclaim > Memory| | | | | | | | |WB|WT|WC|UC] > > And appear correctly as early memory node ranges: > > [ 0.000000] Early memory node ranges > ... > [ 0.000000] node 0: [mem 0x00000000396c0000-0x000000003975ffff] > [ 0.000000] node 0: [mem 0x0000000039760000-0x000000003976ffff] > [ 0.000000] node 0: [mem 0x0000000039770000-0x00000000397affff] > [ 0.000000] node 0: [mem 0x00000000397b0000-0x000000003989ffff] > [ 0.000000] node 0: [mem 0x00000000398a0000-0x00000000398bffff] > > 5. However when the crashkernel is boot'ed I see that although the > same regions are recognized as Reclaim regions they do not appear in > the "Early Memory node range" entries: > > [ 141.348355] Starting crashdump kernel... > [ 141.352269] Bye! > ... > [ 0.000000] efi: 0x000039710000-0x00003975ffff [ACPI Reclaim > Memory| | | | | | | | |WB|WT|WC|UC] > [ 0.000000] efi: 0x000039770000-0x0000397affff [ACPI Reclaim > Memory| | | | | | | | |WB|WT|WC|UC] > ... > [ 0.000000] efi: 0x0000398a0000-0x0000398bffff [ACPI Reclaim > Memory| | | | | | | | |WB|WT|WC|UC] > > ... > [ 0.000000] Early memory node ranges > [ 0.000000] node 0: [mem 0x000000000e800000-0x000000002e7fffff] > [ 0.000000] node 0: [mem 0x0000000039620000-0x00000000396bffff] > [ 0.000000] node 0: [mem 0x0000000039760000-0x000000003976ffff] > [ 0.000000] node 0: [mem 0x00000000397b0000-0x000000003989ffff] > [ 0.000000] node 0: [mem 0x00000000398c0000-0x0000000039d3ffff] > [ 0.000000] node 0: [mem 0x000000003ed30000-0x000000003ed5ffff] > > ( ^^^ No entry for ACPI Reclaim Memory regions) > > 6a. Also I see that during the primary kernel boot: > > 'acpi_os_ioremap' calls 'ioremap_cache' for the ACPI Reclaim Memory regions. > > 6b. But during the crashkernel boot, ''acpi_os_ioremap' calls > 'ioremap' for the ACPI Reclaim Memory regions and not the _cache > variant. > > 7. I think this is because of how the memblock regions are mapped in > 'arch/arm64/mm/mmu.c': > > I am not quite sure if I fully understand the trick we have presently > inside '__init map_mem(pgd_t *pgd)', but reading the comment below: > > /* > * Take care not to create a writable alias for the > * read-only text and rodata sections of the kernel image. > * So temporarily mark them as NOMAP to skip mappings in > * the following for-loop > */ > > I think we are marking only the kernel text and crashkernel regions > with NO_CONT_MAPPINGS or NO_CONT_MAPPINGS and NO_BLOCK_MAPPINGS > > 8. Also, I think now the crashkernel handling changed by > e7cd190385d17790cc3eb3821b1094b00aacf325 (arm64: mark reserved > memblock regions explicitly in iomem), needs to be changed to handle > the change added by Ard to fix this issue on ACPI only machines. > > I have a dirty hack in place, but I would like to have your opinions > about what can be a more concrete fix to this issue (as we mark these > regions as System RAM now rather than NOMAP) and I don't have a DTB > based machine to test on currently. > > Please share your views. > > Regards, > Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
