Resolves: https://issues.redhat.com/browse/RHEL-17451
Explain what factors affect the default crashkernel value and ask users to reset it manually if needed.
Cc: Baoquan He bhe@redhat.com Cc: Jie Li jieli@redhat.com Signed-off-by: Coiby Xu coxu@redhat.com --- kdump.conf.5 | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kdump.conf.5 b/kdump.conf.5 index 9117aa7b..0e6ff211 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -29,7 +29,20 @@ understand how this configuration file affects the behavior of kdump. .B auto_reset_crashkernel <yes|no> .RS determine whether to reset kernel crashkernel parameter to the default value -or not when kexec-tools is updated or a new kernel is installed. +or not when kexec-tools is updated or a new kernel is installed. The default +crashkernel values are different for different architectures and also take the +following factors into consideration, + - AMD Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) + - Mellanox 5th generation network driver + - aarch64 64k kernel + - Firmware-assisted dump (FADump) + +Since the kernel crasherkernel parameter will be only reset when kexec-tools is +updated or a new kernel is installed, you need to call "kdumpctl +reset-crashkernel [--kernel=path_to_kernel]" if you want to use the default +value set after having enabled features like SME/SEV for a specific kernel. And +you should also reboot the system for the new crashkernel value to take effect. +Also see kdumpctl(8).
.B raw <partition> .RS
On 12/19/23 at 01:31pm, Coiby Xu wrote:
Resolves: https://issues.redhat.com/browse/RHEL-17451
Explain what factors affect the default crashkernel value and ask users to reset it manually if needed.
Cc: Baoquan He bhe@redhat.com Cc: Jie Li jieli@redhat.com Signed-off-by: Coiby Xu coxu@redhat.com
kdump.conf.5 | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kdump.conf.5 b/kdump.conf.5 index 9117aa7b..0e6ff211 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -29,7 +29,20 @@ understand how this configuration file affects the behavior of kdump. .B auto_reset_crashkernel <yes|no> .RS determine whether to reset kernel crashkernel parameter to the default value -or not when kexec-tools is updated or a new kernel is installed. +or not when kexec-tools is updated or a new kernel is installed. The default +crashkernel values are different for different architectures and also take the
~~~ s/for/on/ Other than this minor concern, this looks good to me, thx.
Acked-by: Baoquan He bhe@redhat.com
+following factors into consideration,
- AMD Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)
- Mellanox 5th generation network driver
- aarch64 64k kernel
- Firmware-assisted dump (FADump)
+Since the kernel crasherkernel parameter will be only reset when kexec-tools is +updated or a new kernel is installed, you need to call "kdumpctl +reset-crashkernel [--kernel=path_to_kernel]" if you want to use the default +value set after having enabled features like SME/SEV for a specific kernel. And +you should also reboot the system for the new crashkernel value to take effect. +Also see kdumpctl(8).
.B raw <partition> .RS -- 2.43.0
On Tue, Dec 19, 2023 at 04:14:48PM +0800, Baoquan He wrote:
On 12/19/23 at 01:31pm, Coiby Xu wrote:
Resolves: https://issues.redhat.com/browse/RHEL-17451
Explain what factors affect the default crashkernel value and ask users to reset it manually if needed.
Cc: Baoquan He bhe@redhat.com Cc: Jie Li jieli@redhat.com Signed-off-by: Coiby Xu coxu@redhat.com
kdump.conf.5 | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kdump.conf.5 b/kdump.conf.5 index 9117aa7b..0e6ff211 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -29,7 +29,20 @@ understand how this configuration file affects the behavior of kdump. .B auto_reset_crashkernel <yes|no> .RS determine whether to reset kernel crashkernel parameter to the default value -or not when kexec-tools is updated or a new kernel is installed. +or not when kexec-tools is updated or a new kernel is installed. The default +crashkernel values are different for different architectures and also take the
~~~ s/for/on/
I'm curious to ask why "on" is a better choice considering there are more occurrences of "for different architectures" than "on ..." in linux/Documentation,
grep -rI -B1 "different archi" ./ --include=*.rst ./process/5.Posting.rst- combinations of configuration options, use cross-compilers to build for ./process/5.Posting.rst: different architectures, etc. -- ./process/howto.rst- - "Here is a patch that explains what I am trying to describe." ./process/howto.rst: - "I tested it on 5 different architectures..." -- ./arch/arm/setup.rst- MEMC chip control register for Acorn Archimedes and Acorn A5000 ./arch/arm/setup.rst: based machines. May be used differently by different architectures. -- ./arch/arm/setup.rst- Default sound setting on Acorn machines. May be used differently by ./arch/arm/setup.rst: different architectures. -- ./trace/kprobes.rst- ./trace/kprobes.rst:Here are sample overhead figures (in usec) for different architectures:: -- ./userspace-api/unshare.rst- ./userspace-api/unshare.rst: d) Registration of system call number for different architectures
Other than this minor concern, this looks good to me, thx.
Acked-by: Baoquan He bhe@redhat.com
Thanks for reviewing and ack'ing the patch!
On 12/20/23 at 10:05am, Coiby Xu wrote:
On Tue, Dec 19, 2023 at 04:14:48PM +0800, Baoquan He wrote:
On 12/19/23 at 01:31pm, Coiby Xu wrote:
Resolves: https://issues.redhat.com/browse/RHEL-17451
Explain what factors affect the default crashkernel value and ask users to reset it manually if needed.
Cc: Baoquan He bhe@redhat.com Cc: Jie Li jieli@redhat.com Signed-off-by: Coiby Xu coxu@redhat.com
kdump.conf.5 | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kdump.conf.5 b/kdump.conf.5 index 9117aa7b..0e6ff211 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -29,7 +29,20 @@ understand how this configuration file affects the behavior of kdump. .B auto_reset_crashkernel <yes|no> .RS determine whether to reset kernel crashkernel parameter to the default value -or not when kexec-tools is updated or a new kernel is installed. +or not when kexec-tools is updated or a new kernel is installed. The default +crashkernel values are different for different architectures and also take the
~~~ s/for/on/I'm curious to ask why "on" is a better choice considering there are more occurrences of "for different architectures" than "on ..." in linux/Documentation,
Possibly personal preference, not strong opinion. Please take the one you prefer.
grep -rI -B1 "different archi" ./ --include=*.rst ./process/5.Posting.rst- combinations of configuration options, use cross-compilers to build for ./process/5.Posting.rst: different architectures, etc. -- ./process/howto.rst- - "Here is a patch that explains what I am trying to describe." ./process/howto.rst: - "I tested it on 5 different architectures..." -- ./arch/arm/setup.rst- MEMC chip control register for Acorn Archimedes and Acorn A5000 ./arch/arm/setup.rst: based machines. May be used differently by different architectures. -- ./arch/arm/setup.rst- Default sound setting on Acorn machines. May be used differently by ./arch/arm/setup.rst: different architectures. -- ./trace/kprobes.rst- ./trace/kprobes.rst:Here are sample overhead figures (in usec) for different architectures:: -- ./userspace-api/unshare.rst- ./userspace-api/unshare.rst: d) Registration of system call number for different architecturesOther than this minor concern, this looks good to me, thx.
Acked-by: Baoquan He bhe@redhat.com
Thanks for reviewing and ack'ing the patch!
You are welcome.
-
Baoquan He -
Coiby Xu