* x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
@ 2017-10-20 5:52 ` Dave Young
0 siblings, 0 replies; 8+ messages in thread
From: Dave Young @ 2017-10-20 5:52 UTC (permalink / raw)
To: kexec, linux-kernel; +Cc: akpm, bhe, vgoyal, yinghai
Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being compatible with old
kexec-tools).
- If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
- If fails, try to reserve X from MAXMEM top down.
It's more transparent and user-friendly.
If crashkernel is large and the reserved is beyond 896M, old kexec-tools
is not compatible with new kernel because old kexec-tools can not load
kernel at high memory region, there was an old discussion below
(previously posted by Chao Wang):
https://lkml.org/lkml/2013/10/15/601
But actually the behavior is consistent during my test. Suppose
old kernel fail to reserve memory at low areas, kdump does not
work because no memory reserved. With this patch, suppose new kernel
successfully reserved memory at high areas, old kexec-tools still fail
to load kdump kernel (tested 2.0.2), so it is acceptable, no need to
worry about the compatibility.
Here is the test result (kexec-tools 2.0.2, no high memory load
support):
Crashkernel over 4G:
# cat /proc/iomem|grep Crash
be000000-cdffffff : Crash kernel
213000000-21effffff : Crash kernel
# ./kexec -p /boot/vmlinuz-`uname -r`
Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
Then try loading kdump kernel
crashkernel: 896M-4G:
# cat /proc/iomem|grep Crash
96000000-cdefffff : Crash kernel
# ./kexec -p /boot/vmlinuz-4.14.0-rc4+
ELF core (kcore) parse failed
Cannot load /boot/vmlinuz-4.14.0-rc4+
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/kernel/setup.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -568,6 +568,22 @@ static void __init reserve_crashkernel(v
high ? CRASH_ADDR_HIGH_MAX
: CRASH_ADDR_LOW_MAX,
crash_size, CRASH_ALIGN);
+#ifdef CONFIG_X86_64
+ /*
+ * crashkernel=X reserve below 896M fails? Try below 4G
+ */
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ (1ULL << 32),
+ crash_size, CRASH_ALIGN);
+ /*
+ * crashkernel=X reserve below 4G fails? Try MAXMEM
+ */
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ CRASH_ADDR_HIGH_MAX,
+ crash_size, CRASH_ALIGN);
+#endif
if (!crash_base) {
pr_info("crashkernel reservation failed - No suitable area found.\n");
return;
^ permalink raw reply [flat|nested] 8+ messages in thread
* x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
@ 2017-10-20 5:52 ` Dave Young
0 siblings, 0 replies; 8+ messages in thread
From: Dave Young @ 2017-10-20 5:52 UTC (permalink / raw)
To: kexec, linux-kernel; +Cc: akpm, yinghai, vgoyal, bhe
Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being compatible with old
kexec-tools).
- If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
- If fails, try to reserve X from MAXMEM top down.
It's more transparent and user-friendly.
If crashkernel is large and the reserved is beyond 896M, old kexec-tools
is not compatible with new kernel because old kexec-tools can not load
kernel at high memory region, there was an old discussion below
(previously posted by Chao Wang):
https://lkml.org/lkml/2013/10/15/601
But actually the behavior is consistent during my test. Suppose
old kernel fail to reserve memory at low areas, kdump does not
work because no memory reserved. With this patch, suppose new kernel
successfully reserved memory at high areas, old kexec-tools still fail
to load kdump kernel (tested 2.0.2), so it is acceptable, no need to
worry about the compatibility.
Here is the test result (kexec-tools 2.0.2, no high memory load
support):
Crashkernel over 4G:
# cat /proc/iomem|grep Crash
be000000-cdffffff : Crash kernel
213000000-21effffff : Crash kernel
# ./kexec -p /boot/vmlinuz-`uname -r`
Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
Then try loading kdump kernel
crashkernel: 896M-4G:
# cat /proc/iomem|grep Crash
96000000-cdefffff : Crash kernel
# ./kexec -p /boot/vmlinuz-4.14.0-rc4+
ELF core (kcore) parse failed
Cannot load /boot/vmlinuz-4.14.0-rc4+
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/kernel/setup.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -568,6 +568,22 @@ static void __init reserve_crashkernel(v
high ? CRASH_ADDR_HIGH_MAX
: CRASH_ADDR_LOW_MAX,
crash_size, CRASH_ALIGN);
+#ifdef CONFIG_X86_64
+ /*
+ * crashkernel=X reserve below 896M fails? Try below 4G
+ */
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ (1ULL << 32),
+ crash_size, CRASH_ALIGN);
+ /*
+ * crashkernel=X reserve below 4G fails? Try MAXMEM
+ */
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ CRASH_ADDR_HIGH_MAX,
+ crash_size, CRASH_ALIGN);
+#endif
if (!crash_base) {
pr_info("crashkernel reservation failed - No suitable area found.\n");
return;
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
2017-10-20 5:52 ` Dave Young
@ 2017-10-21 7:20 ` Yinghai Lu
-1 siblings, 0 replies; 8+ messages in thread
From: Yinghai Lu @ 2017-10-21 7:20 UTC (permalink / raw)
To: Dave Young
Cc: kexec, Linux Kernel Mailing List, Andrew Morton, Baoquan He, Vivek Goyal
On Thu, Oct 19, 2017 at 10:52 PM, Dave Young <dyoung@redhat.com> wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improve crashkernel=X to:
>
> - First try to reserve X below 896M (for being compatible with old
> kexec-tools).
> - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> - If fails, try to reserve X from MAXMEM top down.
>
> It's more transparent and user-friendly.
ok with me.
But looks like last time Vivek did not like this idea.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
@ 2017-10-21 7:20 ` Yinghai Lu
0 siblings, 0 replies; 8+ messages in thread
From: Yinghai Lu @ 2017-10-21 7:20 UTC (permalink / raw)
To: Dave Young
Cc: Andrew Morton, kexec, Linux Kernel Mailing List, Baoquan He, Vivek Goyal
On Thu, Oct 19, 2017 at 10:52 PM, Dave Young <dyoung@redhat.com> wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improve crashkernel=X to:
>
> - First try to reserve X below 896M (for being compatible with old
> kexec-tools).
> - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> - If fails, try to reserve X from MAXMEM top down.
>
> It's more transparent and user-friendly.
ok with me.
But looks like last time Vivek did not like this idea.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
2017-10-21 7:20 ` Yinghai Lu
@ 2017-10-23 2:04 ` Dave Young
-1 siblings, 0 replies; 8+ messages in thread
From: Dave Young @ 2017-10-23 2:04 UTC (permalink / raw)
To: Yinghai Lu
Cc: kexec, Linux Kernel Mailing List, Andrew Morton, Baoquan He, Vivek Goyal
On 10/21/17 at 12:20am, Yinghai Lu wrote:
> On Thu, Oct 19, 2017 at 10:52 PM, Dave Young <dyoung@redhat.com> wrote:
> > Now crashkernel=X will fail if there's not enough memory at low region
> > (below 896M) when trying to reserve large memory size. One can use
> > crashkernel=xM,high to reserve it at high region (>4G) but it is more
> > convinient to improve crashkernel=X to:
> >
> > - First try to reserve X below 896M (for being compatible with old
> > kexec-tools).
> > - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> > - If fails, try to reserve X from MAXMEM top down.
> >
> > It's more transparent and user-friendly.
>
> ok with me.
Thank you!
>
> But looks like last time Vivek did not like this idea.
>From the old discussion I remember Vivek was fine with this patch:
https://lkml.org/lkml/2013/10/15/601
Thanks
Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
@ 2017-10-23 2:04 ` Dave Young
0 siblings, 0 replies; 8+ messages in thread
From: Dave Young @ 2017-10-23 2:04 UTC (permalink / raw)
To: Yinghai Lu
Cc: Andrew Morton, kexec, Linux Kernel Mailing List, Baoquan He, Vivek Goyal
On 10/21/17 at 12:20am, Yinghai Lu wrote:
> On Thu, Oct 19, 2017 at 10:52 PM, Dave Young <dyoung@redhat.com> wrote:
> > Now crashkernel=X will fail if there's not enough memory at low region
> > (below 896M) when trying to reserve large memory size. One can use
> > crashkernel=xM,high to reserve it at high region (>4G) but it is more
> > convinient to improve crashkernel=X to:
> >
> > - First try to reserve X below 896M (for being compatible with old
> > kexec-tools).
> > - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> > - If fails, try to reserve X from MAXMEM top down.
> >
> > It's more transparent and user-friendly.
>
> ok with me.
Thank you!
>
> But looks like last time Vivek did not like this idea.
From the old discussion I remember Vivek was fine with this patch:
https://lkml.org/lkml/2013/10/15/601
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
2017-10-20 5:52 ` Dave Young
@ 2017-10-24 5:27 ` Dave Young
-1 siblings, 0 replies; 8+ messages in thread
From: Dave Young @ 2017-10-24 5:27 UTC (permalink / raw)
To: kexec, linux-kernel; +Cc: akpm, bhe, vgoyal, yinghai
On 10/20/17 at 01:52pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improve crashkernel=X to:
>
> - First try to reserve X below 896M (for being compatible with old
> kexec-tools).
> - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> - If fails, try to reserve X from MAXMEM top down.
>
> It's more transparent and user-friendly.
>
> If crashkernel is large and the reserved is beyond 896M, old kexec-tools
> is not compatible with new kernel because old kexec-tools can not load
> kernel at high memory region, there was an old discussion below
> (previously posted by Chao Wang):
> https://lkml.org/lkml/2013/10/15/601
>
> But actually the behavior is consistent during my test. Suppose
> old kernel fail to reserve memory at low areas, kdump does not
> work because no memory reserved. With this patch, suppose new kernel
> successfully reserved memory at high areas, old kexec-tools still fail
> to load kdump kernel (tested 2.0.2), so it is acceptable, no need to
> worry about the compatibility.
>
> Here is the test result (kexec-tools 2.0.2, no high memory load
> support):
> Crashkernel over 4G:
> # cat /proc/iomem|grep Crash
> be000000-cdffffff : Crash kernel
> 213000000-21effffff : Crash kernel
> # ./kexec -p /boot/vmlinuz-`uname -r`
> Memory for crashkernel is not reserved
> Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
> Then try loading kdump kernel
>
> crashkernel: 896M-4G:
> # cat /proc/iomem|grep Crash
> 96000000-cdefffff : Crash kernel
> # ./kexec -p /boot/vmlinuz-4.14.0-rc4+
> ELF core (kcore) parse failed
> Cannot load /boot/vmlinuz-4.14.0-rc4+
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/kernel/setup.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> --- linux-x86.orig/arch/x86/kernel/setup.c
> +++ linux-x86/arch/x86/kernel/setup.c
> @@ -568,6 +568,22 @@ static void __init reserve_crashkernel(v
> high ? CRASH_ADDR_HIGH_MAX
> : CRASH_ADDR_LOW_MAX,
> crash_size, CRASH_ALIGN);
> +#ifdef CONFIG_X86_64
> + /*
> + * crashkernel=X reserve below 896M fails? Try below 4G
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + (1ULL << 32),
> + crash_size, CRASH_ALIGN);
> + /*
> + * crashkernel=X reserve below 4G fails? Try MAXMEM
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + CRASH_ADDR_HIGH_MAX,
> + crash_size, CRASH_ALIGN);
> +#endif
> if (!crash_base) {
> pr_info("crashkernel reservation failed - No suitable area found.\n");
> return;
Hmm, forgot to add [PATCH] prefix, will resend this along with other two
crashkernel patches.
Thanks
Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
@ 2017-10-24 5:27 ` Dave Young
0 siblings, 0 replies; 8+ messages in thread
From: Dave Young @ 2017-10-24 5:27 UTC (permalink / raw)
To: kexec, linux-kernel; +Cc: akpm, yinghai, vgoyal, bhe
On 10/20/17 at 01:52pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improve crashkernel=X to:
>
> - First try to reserve X below 896M (for being compatible with old
> kexec-tools).
> - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> - If fails, try to reserve X from MAXMEM top down.
>
> It's more transparent and user-friendly.
>
> If crashkernel is large and the reserved is beyond 896M, old kexec-tools
> is not compatible with new kernel because old kexec-tools can not load
> kernel at high memory region, there was an old discussion below
> (previously posted by Chao Wang):
> https://lkml.org/lkml/2013/10/15/601
>
> But actually the behavior is consistent during my test. Suppose
> old kernel fail to reserve memory at low areas, kdump does not
> work because no memory reserved. With this patch, suppose new kernel
> successfully reserved memory at high areas, old kexec-tools still fail
> to load kdump kernel (tested 2.0.2), so it is acceptable, no need to
> worry about the compatibility.
>
> Here is the test result (kexec-tools 2.0.2, no high memory load
> support):
> Crashkernel over 4G:
> # cat /proc/iomem|grep Crash
> be000000-cdffffff : Crash kernel
> 213000000-21effffff : Crash kernel
> # ./kexec -p /boot/vmlinuz-`uname -r`
> Memory for crashkernel is not reserved
> Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
> Then try loading kdump kernel
>
> crashkernel: 896M-4G:
> # cat /proc/iomem|grep Crash
> 96000000-cdefffff : Crash kernel
> # ./kexec -p /boot/vmlinuz-4.14.0-rc4+
> ELF core (kcore) parse failed
> Cannot load /boot/vmlinuz-4.14.0-rc4+
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/kernel/setup.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> --- linux-x86.orig/arch/x86/kernel/setup.c
> +++ linux-x86/arch/x86/kernel/setup.c
> @@ -568,6 +568,22 @@ static void __init reserve_crashkernel(v
> high ? CRASH_ADDR_HIGH_MAX
> : CRASH_ADDR_LOW_MAX,
> crash_size, CRASH_ALIGN);
> +#ifdef CONFIG_X86_64
> + /*
> + * crashkernel=X reserve below 896M fails? Try below 4G
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + (1ULL << 32),
> + crash_size, CRASH_ALIGN);
> + /*
> + * crashkernel=X reserve below 4G fails? Try MAXMEM
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + CRASH_ADDR_HIGH_MAX,
> + crash_size, CRASH_ALIGN);
> +#endif
> if (!crash_base) {
> pr_info("crashkernel reservation failed - No suitable area found.\n");
> return;
Hmm, forgot to add [PATCH] prefix, will resend this along with other two
crashkernel patches.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-10-24 5:28 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-20 5:52 x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM Dave Young
2017-10-20 5:52 ` Dave Young
2017-10-21 7:20 ` Yinghai Lu
2017-10-21 7:20 ` Yinghai Lu
2017-10-23 2:04 ` Dave Young
2017-10-23 2:04 ` Dave Young
2017-10-24 5:27 ` Dave Young
2017-10-24 5:27 ` Dave Young
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.