I tested the kernel-6.8 on my machine and found that the crashkernel memory
reservation range is consistent with kernel-5.10. However, it's strange that
when crashkernel=512M, the kernel still allocates two memory segments for
crashkernel, as seen in the logs:
[ 0.022640] crashkernel low memory reserved: 0x49000000 - 0x59000000 (256 MB)
[ 0.022641] crashkernel reserved: 0x000000c01f000000 - 0x000000c03f000000
(512 MB)
But only one segment is shown in /proc/iomem:
c01f000000-c03effffff : Crash kernel
Moreover, the conflicting address 53cbd000-53ccffff is still reserved by
someone else:
53cbd000-53ccffff : Reserved
[ 0.029843] e820: update [mem 0x53cbd000-0x53ccffff] usable ==> reserved
It seems there is a kernel bug here.
If you need the complete log, I can send it later.
---------
On 03/19/24 at 4:22pm, Baoquan He wrote:
> On 03/19/24 at 07:24am, chenhaixiang (A) wrote:
> > Thank you for your reply!
> > The kernel version on my machine is kernel-5.10, and the kexec-tools
> > version is
> kexec-tools-2.0.27.
> > However, my issue seems to be a bit different. On my machine, I can see the
> crashkernel memory segment in /proc/iomem. However, for some reason,
> within the address range allocated for crashkernel, there is also a segment
> marked as 'Reserved' (I'm not sure who marked it). In this scenario,
> kexec-tools
> calculates the CRASH MEMORY RANGES incorrectly.
> > ```
>
> crashkernel region can't be reserved again once it's allocated and reserved in
> memblock. There must be something wrong with the code. You can try upstream
> kernel and kexec-tools to see if it exists too. Since you are using an old
> kernel and
> could be on a distros, we may not be able to cover it. Sorry about that.
>
> If you want to debug to find out the reason, I can help give suggestions.
>
> > cat /proc/iomem
> > 2d4fd058-58ffffff : System RAM
> > 49000000-58ffffff : Crash kernel
> > 53cbd000-53ccffff : Reserved
> > ```
> > I'm not sure if the crashkernel memory segment should not include other
> markings, and if not supported, whether kexec-tools should raise an error.
> > Thanks
> > Chen Haixiang
> > ----------
> > On 03/19/24 at 9:38qm, Baoquan He wrote:
> > > Hi,
> > >
> > > On 03/18/24 at 12:00pm, chenhaixiang (A) wrote:
> > > > Dear kexec Community Members,
> > > >
> > > > I encountered an issue while using kexec-tools on my x86_64 machine.
> > > > When there is a segment marked as 'reserved' within the memory
> > > > range
> > > allocated for the crash kernel in /proc/iomem,the output appears as
> > > follows:
> > > > 2d4fd058-60efefff : System RAM
> > > > 2d4fd058-58ffffff : System RAM
> > > > 49000000-58ffffff : Crash kernel
> > > > 53cbd000-53ccffff : Reserved
> > >
> > > What kernel are you using? the version of kernel, and kexec-tools?
> > >
> > > If you are testing on the latest mainline kernel, you could meet the
> > > issue Dave have met and fixed in below patch:
> > >
> > > [PATCH] x86/kexec: do not update E820 kexec table for setup_data
> > > https://lore.kernel.org/all/zez2kos-oozns...@darkstar.users.ipa.redh
> > > at.com/
> > > T/#u
> > >
> > > Thanks
> > > Baoquan
> > >
> > > >
> > > > The crash_memory_range array will encounter incorrect address ranges:
> > > > CRASH MEMORY RANGES
> > > > 000000002d4fd058-0000000048ffffff (0)
> > > > 0000000053cbd000-0000000048ffffff (1)
> > > > 0000000059000000-0000000053ccffff (0)
> > > >
> > > > Read the code, I noticed that the get_crash_memory_ranges()
> > > > function
> > > invokes exclude_region() to handle the splitting of memory regions,
> > > but it seems unable to properly handle the scenario described above.
> > > > The code logic is as follows:
> > > > ...
> > > > if (start < mend && end > mstart) {
> > > > if (start != mstart && end != mend) {
> > > > /* Split memory region */
> > > > crash_memory_range[i].end = start - 1;
> > > > temp_region.start = end + 1;
> > > > temp_region.end = mend;
> > > > temp_region.type = RANGE_RAM;
> > > > tidx = i+1;
> > > > } else if (start != mstart)
> > > > crash_memory_range[i].end = start - 1;
> > > > else
> > > > crash_memory_range[i].start = end + 1;
> > > > }
> > > > ...
> > > > If start < mstart < mend < end, resulting in
> > > > crash_memory_range[i].end
> > > becoming less than crash_memory_range[i].start, leading to incorrect
> > > address ranges.
> > > > I would like to know if this behavior is reasonable and whether it
> > > > is necessary to
> > > validate the address ranges for compliance at the end.
> > > >
> > > > Thank you for your time and assistance.
> > > >
> > > > Chen Haixiang
> > > >
> > > > _______________________________________________
> > > > kexec mailing list
> > > > kexec@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/kexec
> > > >
> >
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
