[Crash-utility] Re: [PATCH] loongarch64: fix mem section init failure

On 8/24/26 20:13, Dave Young wrote: > > > On 8/24/26 3:02 PM, Dave Young wrote: >> >> The loongarch64 SECTION_SIZE_BITS does not match the mainline kernel code. >> crash test failed with mem_section init failure due to access non exist >> memory address for mem sections caused by wrong NR_SECTION_ROOTS > > error msg: > crash: read error: kernel virtual address: 90000000a0000000 type: "memory section" > > > BTW, I checked mainline kernel log the SECTION_SIZE_BITS is 29 since the first commit. So I suspect previous crash loongarch support was tested with some vendor or distribution kernel. Wangming, can you confirm? If this is true then please ensure patches always tested with mainline kernel. > > Thanks! Hi Dave, Thanks for finding this. I checked the history again. The value 28 in crash was not just an arbitrary downstream setting. LoongArch mainline has used SECTION_SIZE_BITS=29 since the initial upstream support, but there is a known issue with that value on LoongArch systems. With SECTION_SIZE_BITS=29, one memsection covers 512 MB, while the low physical address layout contains 256 MB of RAM followed by a 256 MB I/O register region. As a result, the I/O region may be treated as valid memory by the generic pfn_valid() implementation. There was already an upstream kernel patch in 2022 titled "LoongArch: Fix memsection size" which changed SECTION_SIZE_BITS from 29 to 28 to avoid accessing the I/O region during suspend/resume. Our downstream kernels have carried this change, which is why the original crash LoongArch support used 28. So I think there are actually two issues here: The mainline LoongArch kernel should probably be fixed to use SECTION_SIZE_BITS=28. crash should ideally obtain SECTION_SIZE_BITS from VMCOREINFO instead of hard-coding either 28 or 29, so that it can handle both existing mainline kernels and downstream kernels correctly.

The kernel already exports NUMBER(SECTION_SIZE_BITS) in VMCOREINFO, so I think using that value when available would be more robust than simply changing the crash default from 28 to 29. I will also revisit the old kernel-side fix and see about getting it upstream.

Thanks, Ming > > >> >> Signed-off-by: Dave Young <yangrr.2009(a)tsinghua.org.cn&gt; >> --- >> defs.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> Index: crash/defs.h >> =================================================================== >> --- crash.orig/defs.h 2026-08-18 09:40:48.392309457 +0800 >> +++ crash/defs.h 2026-08-24 14:46:52.133057387 +0800 >> @@ -3903,7 +3903,7 @@ >> >> #define TIF_SIGPENDING (1) >> >> -#define _SECTION_SIZE_BITS 28 >> +#define _SECTION_SIZE_BITS 29 >> #define _MAX_PHYSMEM_BITS 48 >> #endif /* LOONGARCH64 */ >> >> -- >> Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io >> To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io >> https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ >> Contribution Guidelines: https://github.com/crash-utility/crash/wiki -- Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki