On 02/22/2019 11:26 AM, Kairui Song wrote:
Hi Hari, Thanks for the update.
On Fri, Feb 1, 2019 at 6:26 PM Hari Bathini <hbathini(a)linux.ibm.com> wrote:
> With kernel commit 0823c68b054b ("powerpc/fadump: re-register firmware-
> assisted dump if already registered") support is enabled to re-register
> when FADump is alredy registered. Leverage that option in kdump scripts.
> Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com>
> kdumpctl | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
> diff --git a/kdumpctl b/kdumpctl
> index de6da39..7b8013c 100755
> --- a/kdumpctl
> +++ b/kdumpctl
> @@ -1047,7 +1047,8 @@ reload()
> if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
> - stop_fadump
> + reload_fadump
> + return $?
> @@ -1103,6 +1104,22 @@ stop_kdump()
> return 0
> + echo 1 > $FADUMP_REGISTER_SYS_NODE
> + if [ $? == 0 ]; then
> + echo "fadump: re-registered successfully"
> + return 0
> + else
> + # FADump could fail on older kernel where re-register
> + # support is not enabled. Try stop/start from userspace
> + # to handle such scenario.
> + stop_fadump
> + start_fadump
stop_fadump and start_fadump may also fail ), if stop_fadump failed
Yes, it could
happen based on the kernel code.
start_fadump should not be called or else it will wrongly report
"registered successfully". Would it be better to let reload_fadump
return right after try to re-register and don't try to fallback to
stop/start? Then callee would try to call reload_fadump() first, if
successed it return, else fail back to ordinary routine.
What about return immediately after stop_fadump() if error happens, and
warning the user about it? I think if this error happens, then it is
unlikely to unregister successfully any longer.
>> + return $?
>> + fi
> Best Regards,
> Kairui Song
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: