kexec-tools/kdump.sysconfig.aarch64

54 lines
2.3 KiB
Plaintext
Raw Normal View History

Add aarch64 specific kdump.sysconfig and use 'nr_cpus' instead of 'maxcpus' 'maxcpus' setting normally don't work on several kdump enabled systems due to a known udev issue. Currently the fedora kdump configuration is set as the following on the aarch64 systems: # cat /etc/sysconfig/kdump <..snip..> # This variable lets us append arguments to the current kdump # commandline after processed by KDUMP_COMMANDLINE_REMOVE # KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 reset_devices" <..snip..> Since the 'maxcpus' setting doesn't limit the number of SMP CPUs, so the kdump kernel still boots with all CPUs available on the system. For e.g on the qualcomm amberwing its 46 CPUs: # lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 46 On-line CPU(s) list: 0-45 Thread(s) per core: 1 Core(s) per socket: 46 Socket(s): 1 NUMA node(s): 1 Vendor ID: Qualcomm Model: 1 Model name: Falkor Stepping: 0x0 CPU max MHz: 2600.0000 CPU min MHz: 600.0000 BogoMIPS: 40.00 L1d cache: 32K L1i cache: 64K L2 cache: 512K L3 cache: 58880K NUMA node0 CPU(s): 0-45 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm This causes the memory consumption in the kdump kernel to swell up and we can end up having OOM issues in the kdump kernel boot. Whereas if we use 'nr_cpus=1' in the bootargs, the number of SMP CPUs in the kdump kernel get limited to 1. The 'swiotlb=noforce' setting in bootargs provide us extra guarding, to ensure the crash kernel size requirements do not swell on systems which support swiotlb. With the above settings, crashkernel boots properly (without OOM) on all the aarch64 boards I could test on - qualcomm amberwings, hp-moonshots and hpe-apache (thunderx2) for crash dump saving on local disk. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com>
2019-05-27 11:29:07 +00:00
# Kernel Version string for the -kdump kernel, such as 2.6.13-1544.FC5kdump
# If no version is specified, then the init script will try to find a
# kdump kernel with the same version number as the running kernel.
KDUMP_KERNELVER=""
# The kdump commandline is the command line that needs to be passed off to
# the kdump kernel. This will likely match the contents of the grub kernel
# line. For example:
# KDUMP_COMMANDLINE="ro root=LABEL=/"
# Dracut depends on proper root= options, so please make sure that appropriate
# root= options are copied from /proc/cmdline. In general it is best to append
# command line options using "KDUMP_COMMANDLINE_APPEND=".
# If a command line is not specified, the default will be taken from
# /proc/cmdline
KDUMP_COMMANDLINE=""
# This variable lets us remove arguments from the current kdump commandline
# as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline
# NOTE: some arguments such as crashkernel will always be removed
KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb cma hugetlb_cma"
Add aarch64 specific kdump.sysconfig and use 'nr_cpus' instead of 'maxcpus' 'maxcpus' setting normally don't work on several kdump enabled systems due to a known udev issue. Currently the fedora kdump configuration is set as the following on the aarch64 systems: # cat /etc/sysconfig/kdump <..snip..> # This variable lets us append arguments to the current kdump # commandline after processed by KDUMP_COMMANDLINE_REMOVE # KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 reset_devices" <..snip..> Since the 'maxcpus' setting doesn't limit the number of SMP CPUs, so the kdump kernel still boots with all CPUs available on the system. For e.g on the qualcomm amberwing its 46 CPUs: # lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 46 On-line CPU(s) list: 0-45 Thread(s) per core: 1 Core(s) per socket: 46 Socket(s): 1 NUMA node(s): 1 Vendor ID: Qualcomm Model: 1 Model name: Falkor Stepping: 0x0 CPU max MHz: 2600.0000 CPU min MHz: 600.0000 BogoMIPS: 40.00 L1d cache: 32K L1i cache: 64K L2 cache: 512K L3 cache: 58880K NUMA node0 CPU(s): 0-45 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm This causes the memory consumption in the kdump kernel to swell up and we can end up having OOM issues in the kdump kernel boot. Whereas if we use 'nr_cpus=1' in the bootargs, the number of SMP CPUs in the kdump kernel get limited to 1. The 'swiotlb=noforce' setting in bootargs provide us extra guarding, to ensure the crash kernel size requirements do not swell on systems which support swiotlb. With the above settings, crashkernel boots properly (without OOM) on all the aarch64 boards I could test on - qualcomm amberwings, hp-moonshots and hpe-apache (thunderx2) for crash dump saving on local disk. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com>
2019-05-27 11:29:07 +00:00
# This variable lets us append arguments to the current kdump commandline
# after processed by KDUMP_COMMANDLINE_REMOVE
KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory udev.children-max=2 panic=10 swiotlb=noforce novmcoredd cma=0 hugetlb_cma=0"
Add aarch64 specific kdump.sysconfig and use 'nr_cpus' instead of 'maxcpus' 'maxcpus' setting normally don't work on several kdump enabled systems due to a known udev issue. Currently the fedora kdump configuration is set as the following on the aarch64 systems: # cat /etc/sysconfig/kdump <..snip..> # This variable lets us append arguments to the current kdump # commandline after processed by KDUMP_COMMANDLINE_REMOVE # KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 reset_devices" <..snip..> Since the 'maxcpus' setting doesn't limit the number of SMP CPUs, so the kdump kernel still boots with all CPUs available on the system. For e.g on the qualcomm amberwing its 46 CPUs: # lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 46 On-line CPU(s) list: 0-45 Thread(s) per core: 1 Core(s) per socket: 46 Socket(s): 1 NUMA node(s): 1 Vendor ID: Qualcomm Model: 1 Model name: Falkor Stepping: 0x0 CPU max MHz: 2600.0000 CPU min MHz: 600.0000 BogoMIPS: 40.00 L1d cache: 32K L1i cache: 64K L2 cache: 512K L3 cache: 58880K NUMA node0 CPU(s): 0-45 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm This causes the memory consumption in the kdump kernel to swell up and we can end up having OOM issues in the kdump kernel boot. Whereas if we use 'nr_cpus=1' in the bootargs, the number of SMP CPUs in the kdump kernel get limited to 1. The 'swiotlb=noforce' setting in bootargs provide us extra guarding, to ensure the crash kernel size requirements do not swell on systems which support swiotlb. With the above settings, crashkernel boots properly (without OOM) on all the aarch64 boards I could test on - qualcomm amberwings, hp-moonshots and hpe-apache (thunderx2) for crash dump saving on local disk. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com>
2019-05-27 11:29:07 +00:00
# Any additional kexec arguments required. In most situations, this should
# be left empty
#
# Example:
# KEXEC_ARGS="--elf32-core-headers"
KEXEC_ARGS=""
#Where to find the boot image
#KDUMP_BOOTDIR="/boot"
#What is the image type used for kdump
KDUMP_IMG="vmlinuz"
# Logging is controlled by following variables in the first kernel:
# - @var KDUMP_STDLOGLVL - logging level to standard error (console output)
# - @var KDUMP_SYSLOGLVL - logging level to syslog (by logger command)
# - @var KDUMP_KMSGLOGLVL - logging level to /dev/kmsg (only for boot-time)
#
# In the second kernel, kdump will use the rd.kdumploglvl option to set the
# log level in the above KDUMP_COMMANDLINE_APPEND.
# - @var rd.kdumploglvl - logging level to syslog (by logger command)
# - for example: add the rd.kdumploglvl=3 option to KDUMP_COMMANDLINE_APPEND
#
# Logging levels: no logging(0), error(1),warn(2),info(3),debug(4)
#
# KDUMP_STDLOGLVL=3
# KDUMP_SYSLOGLVL=0
# KDUMP_KMSGLOGLVL=0