kexec September 2016

kexec@lists.fedoraproject.org

4 participants
5 discussions

[PATCH 1/2] kdump/fadump: fix network interface name when switching from fadump to kdump
by Hari Bathini 03 Oct '16

03 Oct '16

When a remote dump target is specified, kdump dracut module prefixes 'kdump-' to network interface name (ifname) as kernel assigned names are not persistent. In fadump mode, kdump dracut module is added to the default initrd, which adds the 'kdump-' prefix to the ifname of the prodcution kernel itself. If fadump mode is disabled after this, kdump dracut module picks the ifname that is already prefixed with 'kdump-' in the production kernel and adds another 'kdump-' to it, making the ifname something like kdump-kdump-eth0 for kdump kernel. Eventually, kdump kernel fails with below traces: dracut-initqueue[246]: RTNETLINK answers: Network is unreachable dracut-initqueue[246]: arping: Device kdump-kdump-eth0 not available. The ip command shows the below: kdump:/# ip addr show kdump-kdump-eth0 2: kdump-kdump-eth: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 \ qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 22:82:87:7b:98:02 brd ff:ff:ff:ff:ff:ff inet6 2002:903:15f:550:2082:87ff:fe7b:9802/64 scope global \ mngtmpaddr dynamic valid_lft 2591890sec preferred_lft 604690sec inet6 fe80::2082:87ff:fe7b:9802/64 scope link valid_lft forever preferred_lft forever kdump:/# The trailing 0 from kdump-kdump-eth0 is missing in the ifname, probably truncated while setting. This patch fixes this by avoiding addition of the prefix 'kdump-' when such prefix is already present in the ifname. Signed-off-by: Hari Bathini <hbathini(a)linux.vnet.ibm.com> --- dracut-module-setup.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 68e0ff8..490501a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -161,7 +161,8 @@ kdump_get_perm_addr() { kdump_setup_ifname() { local _ifname - if [[ $1 =~ eth* ]]; then + # If ifname has 'kdump-' prefix, don't add it again + if [[ $1 =~ eth* ]] && [[ ! $1 =~ ^kdump-* ]]; then _ifname="kdump-$1" else _ifname="$1"

2 16

[PATCH 0/2] check /etc/fstab modification only when it exists
by Pratyush Anand 16 Sep '16

16 Sep '16

Patch 1 is just a cleanup for some left over duplicate code. Patch 2 is the actual resolution to fix /etc/fstab modification check. Now it will check for modification only when this file exists. Pratyush Anand (2): kdumpctl: Kill duplicate code related to file modication check kdumpctl: check /etc/fstab modification only when it exists kdumpctl | 23 ++--------------------- mkdumprd | 2 +- 2 files changed, 3 insertions(+), 22 deletions(-) -- 2.7.4

3 4

[PATCH v2 1/2] kdump/fadump: fix network interface name when switching from fadump to kdump
by Hari Bathini 14 Sep '16

14 Sep '16

When a remote dump target is specified, kdump dracut module prefixes 'kdump-' to network interface name (ifname) as kernel assigned names are not persistent. In fadump mode, kdump dracut module is added to the default initrd, which adds the 'kdump-' prefix to the ifname of the prodcution kernel itself. If fadump mode is disabled after this, kdump dracut module picks the ifname that is already prefixed with 'kdump-' in the production kernel and adds another 'kdump-' to it, making the ifname something like kdump-kdump-eth0 for kdump kernel. Eventually, kdump kernel fails with below traces: dracut-initqueue[246]: RTNETLINK answers: Network is unreachable dracut-initqueue[246]: arping: Device kdump-kdump-eth0 not available. The ip command shows the below: kdump:/# ip addr show kdump-kdump-eth0 2: kdump-kdump-eth: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 \ qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 22:82:87:7b:98:02 brd ff:ff:ff:ff:ff:ff inet6 2002:903:15f:550:2082:87ff:fe7b:9802/64 scope global \ mngtmpaddr dynamic valid_lft 2591890sec preferred_lft 604690sec inet6 fe80::2082:87ff:fe7b:9802/64 scope link valid_lft forever preferred_lft forever kdump:/# The trailing 0 from kdump-kdump-eth0 is missing in the ifname, probably truncated while setting. This patch fixes this by avoiding addition of the prefix 'kdump-' when such prefix is already present in the ifname. Signed-off-by: Hari Bathini <hbathini(a)linux.vnet.ibm.com> --- * No changes from v1. dracut-module-setup.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 68e0ff8..490501a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -161,7 +161,8 @@ kdump_get_perm_addr() { kdump_setup_ifname() { local _ifname - if [[ $1 =~ eth* ]]; then + # If ifname has 'kdump-' prefix, don't add it again + if [[ $1 =~ eth* ]] && [[ ! $1 =~ ^kdump-* ]]; then _ifname="kdump-$1" else _ifname="$1"

1 1

[PATCH 0/2] fix target identification for systems without initrd
by Pratyush Anand 12 Sep '16

12 Sep '16

Patch 1 is just a cleanup for removing duplicate statements. Patch 2 is the actual resolution to fix target identification for systems without initrd. It resolves https://bugzilla.redhat.com/show_bug.cgi?id=1373958. Pratyush Anand (2): kdumpctl: remove duplicate statement kdumpctl: fix target identification for systems without initrd kdump-lib.sh | 6 +++++- kdumpctl | 10 +++------- 2 files changed, 8 insertions(+), 8 deletions(-) -- 2.7.4

2 3

[RFC PATCH 0/3] Implement "systemctl reload kdump.service"
by Xunlei Pang 11 Sep '16

11 Sep '16

On very large modern machines, there are a huge amount of memory deplored, the initialization of the memory is very slow, thus some new technology is introduced in Linux kernel to delay memory(pagetable) initialization after the system is boot up using runtime memory hotplug. Unfortunately, the frequent memory onlining will trigger too many memory online kernel/udev events, thereby causing some trouble to kdump.service which uses udev (98-kexec.rules) to listen to the memory/cpu hotplug events and further trigger kdump.service restart(because kdump must update memory layout for memory bank changes, or note elfcorehdr info for cpu changes). The most annoying one is the cpus are busying doing "kdump.service restart" for a long time. For example, The current rules in 98-kexec.rules for memory online is: SUBSYSTEM=="memory", ACTION=="online", PROGRAM="/bin/systemctl try-restart kdump.service" There is no way to control the number of kernel events delivered to udev and futher to systemd udev threads to invoke PROGRAM. For systemd service there are several parameters to control the number of service restart: "StartLimitInterval" and "StartLimitBurst". But the service will become unvailable(with some failed status) if the number of service restart is over the limit. They don't help our situation(kdump.service has StartLimitInterval=0, allowing unlimited number of service restart). We here provide a doable solution to mitigate this kdump service restart issue(will hopefull eliminate the side effect of hogging the cpu for some perceivable period): From above-mentioned example, we know udev calls "systemctl try-restart kdump.service" for every event, the whole process of restart is actually very time-consuming, as kdump checks all the possible conditions to decide if the initramfs rebuild is needed or not. However for cpu/memory hotplug scenarios, we don't need any initramfs check, actually we can simply reload the kernel and all set. This patch series, provide a new function reload_dump() to be used by kdump.service reload, and further used by 98-kexec udev PROGRAM. Here is some comparable time data to show the effect of this patch series: 1)/bin/systemctl try-restart kdump.service: 15:07:56 localhost systemd: Stopping Crash recovery kernel arming... 15:07:56 localhost kdumpctl: kexec: unloaded kdump kernel 15:07:56 localhost kdumpctl: Stopping kdump: [OK] 15:07:56 localhost systemd: Starting Crash recovery kernel arming... 15:08:02 localhost kdumpctl: kexec: loaded kdump kernel 15:08:02 localhost kdumpctl: Starting kdump: [OK] 15:08:02 localhost systemd: Started Crash recovery kernel arming. 2)/bin/systemctl reload-or-try-restart kdump.service: 15:09:24 localhost kdumpctl: kexec: loaded kdump kernel 15:09:24 localhost systemd: Reloaded Crash recovery kernel arming. Another test fact is that: 1)/bin/systemctl try-restart kdump.service: I modified the udev/rules.d/98-kexec.rules for cpu subsytem to use: SUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl try-restart kdump.service" SUBSYSTEM=="cpu", ACTION=="offline", PROGRAM="/bin/systemctl try-restart kdump.service" And executed the follow shell commands for seconds which triggers a huge amount of events: echo 0 > /sys/devices/system/cpu/cpu3/online; echo 1 > /sys/devices/system/cpu/cpu3/online; Then observed the cpu utilization using top, the total kdump restart processes lasted more than half an hour(maybe over an hour IIRC). 2)/bin/systemctl reload-or-try-restart kdump.service: SUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl reload-or-try-restart kdump.service" SUBSYSTEM=="cpu", ACTION=="offline", PROGRAM="/bin/systemctl reload-or-try-restart kdump.service" Executed the same shell commands for seconds to trigger events, and observed the cpu utilization using top, the total kdump reload processes lasted for a couple of minutes. Xunlei Pang (3): kdumpctl: introduce prepare_dump() to refactor some code kdumpctl: provide reload_kdump to be used for memory/cpu hotplug kdump.service: add systemctl "ExecReload" for kdump kdump.service | 1 + kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 49 insertions(+), 13 deletions(-) -- 1.8.3.1

4 11

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

kexec September 2016