------- Comment From <email address hidden> 2018-03-22 13:18 EDT-------
(In reply to comment #32)
> (In reply to comment #31)
> > Could you please comment as to whether the workaround resolved the issue?
>
> Yes, the workaround resolves the issue. But could we have a udev rule added
> in kdump-tools
> to trigger kdump-tools.service restart after a DLPAR memory/CPU add/remove
> operation
> instead of manually restarting kdump-tools service after a DLPAR operation..
------- Comment From <email address hidden> 2018-03-22 13:18 EDT-------
(In reply to comment #32)
> (In reply to comment #31)
> > Could you please comment as to whether the workaround resolved the issue?
>
> Yes, the workaround resolves the issue. But could we have a udev rule added
> in kdump-tools
> to trigger kdump-tools.service restart after a DLPAR memory/CPU add/remove
> operation
> instead of manually restarting kdump-tools service after a DLPAR operation..
Basically, a udev rule file that looks like this:
SUBSYSTEM= ="memory" , ACTION=="online", PROGRAM= "/bin/systemctl try-restart kdump-tools. service" ="memory" , ACTION=="offline", PROGRAM= "/bin/systemctl try-restart kdump-tools. service" "/bin/systemctl try-restart kdump-tools. service" "/bin/systemctl try-restart kdump-tools. service"
SUBSYSTEM=
SUBSYSTEM=="cpu", ACTION=="add", PROGRAM=
SUBSYSTEM=="cpu", ACTION=="remove", PROGRAM=
put in "/lib/udev/rules.d" dir as part of the kdump-tools package to avoid the need to manually
reload kdump..
Thanks
Hari