When large amount of memory, about 1TB, is removed with DLPAR memory
remove operation, kdump reload could fail due to race condition with
device tree property update. In such scenario, the subsequent kdump
reload requests would also fail as reload() only proceeds if current
load status is active. Since the possibility of this race condition
couldn't be wished away due to the nature of the scenario, workaround
it by proceeding to load even if current load status is not active as
long as kdump service is active, which kdump udev rules already check
for.
Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com>
---
kdumpctl | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kdumpctl b/kdumpctl
index 048e9f5..2d21a41 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -1116,8 +1116,7 @@ reload()
{
check_current_status
if [ $? -ne 0 ]; then
- echo "Kdump is not running: [WARNING]"
- return 0
+ echo "Kdump was not running: [WARNING]"
fi
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
Show replies by date