Re: Question about Address Range Validation in Crash Kernel Allocation

["chenhaixiang (A)" <chenhaixiang3@huawei.com>]

> > I'm sorry for the delay. Here are some details from the boot log and
> /proc/iomem:
> > The Boot log:
> > [    0.000000] Linux version 6.8.0 (root@localhost.localdomain) (gcc (GCC)
> 10.3.1, GNU ld (GNU Binutils) 2.37) #3 SMP PREEMPT_DYNAMIC Wed Mar 20
> 11:46:11 UTC 2024
> > [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.8.0
> root=/dev/mapper/root ro crashkernel=512M resume=/dev/mapper/swap
> rd.lvm.lv=root rd.lvm.lv=swap crash_kexec_post_notifiers softlockup_panic=1
> reserve_kbox_mem=16M fsck.mode=auto fsck.repair=yes panic=3
> nmi_watchdog=1 quiet rd.shell=0 memblock=debug efi=debug
> console=ttyS0,115200n8 console=tty0
> ......snip...
> > [    0.022622] memblock_phys_alloc_range: 536870912 bytes align=0x1000000
> from=0x0000000000000000 max_addr=0x0000000100000000
> reserve_crashkernel_generic+0x7c/0x220
> > [    0.022628] memblock_phys_alloc_range: 536870912 bytes align=0x1000000
> from=0x0000000100000000 max_addr=0x0000400000000000
> reserve_crashkernel_generic+0x7c/0x220
> > [    0.022632] memblock_reserve: [0x000000c01f000000-0x000000c03effffff]
> memblock_alloc_range_nid+0xee/0x170
> > [    0.022634] memblock_phys_alloc_range: 268435456 bytes align=0x1000000
> from=0x0000000000000000 max_addr=0x0000000100000000
> reserve_crashkernel_generic+0x11d/0x220
> > [    0.022638] memblock_reserve: [0x0000000049000000-0x0000000058ffffff]
> memblock_alloc_range_nid+0xee/0x170
> > [    0.022640] crashkernel low memory reserved: 0x49000000 - 0x59000000
> (256 MB)
> > [    0.022641] crashkernel reserved: 0x000000c01f000000 -
> 0x000000c03f000000 (512 MB)
> 
> Here, crashkernel,low is reserved in region:  [0x49000000 - 0x59000000] (256
> MB)
>       crashkernel,high is reserved in region: [0x000000c01f000000 -
> 0x000000c03f000000] (512 MB) ......
> > [    0.029839] memblock_reserve: [0x000000c03ffff740-0x000000c03fffff7f]
> memblock_alloc_range_nid+0xee/0x170
> > [    0.029843] e820: update [mem 0x53cbd000-0x53ccffff] usable ==>
> reserved
> > [    0.029861] TSC deadline timer available
> 
> Then here, region [0x53cbd000-0x53ccffff] is reserved in e820, and print abvoe
> "usable ==> reserved". This should be the step which prevents earlier reserved
> crashkernel,low from being added to iomem tree. I am not sure what triggered
> the e820 update.
Current analysis suggests that efi_reserve_boot_services() is causing the update of the e820 table.

> 
> How do you boot into your new 6.8.0 kernel? Used kexec -l to jump into the 2nd
> kernel, or reboot from bios/firmware boot up into 6.8.0?
It's reboot from bios boot up into 6.8.0. I attempted to revert the below patch,
 and this time the conflicting segment "53cbd000-53ccffff" also appeared in the /proc/iomem
 of the 6.8 kernel.

2d4fd058-60efefff : System RAM
  2d4fd058-58ffffff : System RAM
    49000000-58ffffff : Crash kernel
      53cbd000-53ccffff : Reserved
60eff000-704fefff : Reserved
--
  93dd424000-93dd9fffff : Kernel bss
  c01f000000-c03effffff : Crash kernel
d0000000000-d0fffffffff : PCI Bus 0000:00
  d0000000000-d00001fffff : PCI Bus 0000:01
> 
> Reverting below commit should fix your problem, can you try it?
> 
> commit 4a693ce65b186fddc1a73621bd6f941e6e3eca21
> Author: Huacai Chen <chenhuacai@kernel.org>
> Date:   Fri Dec 29 16:02:13 2023 +0800
> 
>     kdump: defer the insertion of crashkernel resources


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec