[PATCH 1/2] kdump/fadump: fix network interface name when switching
from fadump to kdump
by Hari Bathini
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"
6 years, 8 months
[PATCH 0/2] check /etc/fstab modification only when it exists
by Pratyush Anand
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
6 years, 8 months
[PATCH v2 1/2] kdump/fadump: fix network interface name when
switching from fadump to kdump
by Hari Bathini
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"
6 years, 8 months
[RFC PATCH 0/3] Implement "systemctl reload kdump.service"
by Xunlei Pang
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
6 years, 8 months
