Commit Graph

5 Commits

Author SHA1 Message Date
Sourabh Jain
a8523f55a8
fadump/udev: do not re-register fadump if kernel hotplug ready
With the introduction of kernel commit c6c5b14dac0d ("powerpc: make fadump
resilient with memory add/remove events") linux kernel now internally manages
the update of elfcorehdr during memory add/remove events. So no need to
re-register fadump if the /sys/kernel/fadump/hotplug_ready is set to 1.

No impact for kernels that do not have /sys/kernel/fadump/hotplug_ready
sysfs.

Relevant kernel commit links:
1. https://msgid.link/20240422195932.1583833-2-sourabhjain@linux.ibm.com
2. https://msgid.link/20240422195932.1583833-3-sourabhjain@linux.ibm.com

Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
2024-05-31 11:32:27 +08:00
Baoquan He
69d61bb3e3
update 98-kexec rules for crash hotplug
In kernel, with the support of cpu/memory hotplug on crash, kdump
reloading only needs to update the elfcorehdr.

To realize the benefits, we need prevent udev from updating kdump
kernel on hot un/plug changes when detecting that the crash_hotplug
sysfs nodes are present.

Link: https://lore.kernel.org/lkml/20230814214446.6659-1-eric.devolder@oracle.com/
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d68b4b6f307d155475cce541f2aee938032ed22e
Signed-off-by: Baoquan He <bhe@redhat.com>
2024-05-31 11:32:26 +08:00
Sourabh Jain
fc7c65312a powerpc: update fadump sysfs node path
The fadump sysfs nodes /sys/kernel/fadump_[enabled|registered], have
been relocated to /sys/kernel/fadump/[enabled|registered] by kernel
commits d418b19f34ed ("powerpc/fadump: Reorganize /sys/kernel/fadump_*
sysfs files").

To ensure compatibility, symbolic links were added for each relocated
sysfs entry. Nonetheless, note that these symbolic links might be
removed later, as they have been deprecated by kernel commit
3f5f1f22ef10 ("Documentation/ABI: Mark /sys/kernel/fadump_* sysfs files
deprecated")

This patch updates the scripts to use the updated fadump sysfs files.

Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2023-09-01 13:48:28 +08:00
Sourabh Jain
6a2e820d87 Stop reloading kdump service on CPU hotplug event for FADump
As FADump does not require an explicit elfcorehdr update whenever there is CPU
hotplug event so let's stop kdump service reload for FADump when CPU hotplug
event is triggered.

A new label is added to handle CPU and memory hotplug events separately. The
updated CPU hotplug event handler make sure that kdump service should not be
reloaded when FADump is configured.

Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
2021-03-10 16:24:42 +08:00
Pingfan Liu
a585f981bd kexec.rules: create dedicated udev rules for ppc64
On powerpc, after hot add cpu and trigger crash on the hot-added cpu, the
kdump kernel hangs after "I'm in purgatory".

The current udev rules expects the dtb to be rebuit on cpu add/remove event.
But since powerpc does not follow the standard cpu hot add framework, it
only ejects online/offline event to user space when cpu is hot
added/removed, instead of add/remove event.  Pingfan tried fixing that but
it didn't please the maintainer as it breaks some old userspace tools.

Due to the failure of dtb's rebuilding, KDump kernel fails to get the
'boot_cpuid' and eventually fails to boot [see early_init_dt_scan_cpus() in
arch/powerpc/kernel/prom.c file] if system crashes on hot-added CPU.

Work around it by changing udev rules on powerpc to onlne/offline.

As for offline message, it is even useless on powerpc, and can be dropped.
See the explain: On powerpc, /sys/devices/system/cpu/cpuX nodes are present
for all "possible", irrespective of whether a CPU is hot-added/removed.
crash_notes are already built for all /sys/devices/system/cpu/cpuX nodes and
these nodes are present for all "possible" CPUs
(online/offline/could-be-hot-removed/could-be-hot-added)

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-05-06 16:22:28 +08:00