On 07/25/2014 05:40 PM, Vivek Goyal wrote:
On Fri, Jul 25, 2014 at 02:53:49PM +0800, WANG Chao wrote:
> On 07/24/14 at 02:51pm, Vivek Goyal wrote:
>> On Fri, Jul 25, 2014 at 12:09:22AM +0530, Hari Bathini wrote:
>>> The script dracut-kdump.sh is responsible for capturing vmcore during
>>> second kernel boot. Currently this script gets installed into kdump
>>> initrd as part of kdumpbase dracut module.
>>>
>>> With fadump support, 'dracut-kdump.sh' script also gets installed
into
>>> default initrd to capture vmcore generated by firmware assisted dump.
>>> Thus in fadump case, the same initrd is going to be used for normal
>>> boot as well as boot after system crash. Hence a check is required to
>>> see if it is a normal boot or boot after crash.
>>>
>>> A new node "ibm,kernel-dump" is added, to the device tree, by
firmware
>>> to notify kernel if it is booting after crash. The below patch adds a
>>> check for this node before executing steps to capture vmcore. This
>>> check will help bypassing the vmcore capture steps during normal boot
>>> process.
>>>
>>> Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
>>> Signed-off-by: Hari Bathini <hbathini(a)linux.vnet.ibm.com>
>>> ---
>>> dracut-kdump.sh | 5 +++++
>>> kdumpctl | 6 +++++-
>>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/dracut-kdump.sh b/dracut-kdump.sh
>>> index cb13d92..9958317 100755
>>> --- a/dracut-kdump.sh
>>> +++ b/dracut-kdump.sh
>>> @@ -1,5 +1,10 @@
>>> #!/bin/sh
>>>
>>> +# continue here only if we have to save dump.
>>> +if [ -f /etc/fadump.initramfs ] && [ ! -f
/proc/device-tree/rtas/ibm,kernel-dump ]; then
>>> + return
>>> +fi
>>> +
>> This is much better.
>>
>> What about the failure case. Say saving vmcore fails. Current default
>> is to "reboot" the system. What are you expecting in case of
"fadump"?
>>
>> I don't think you will like to reboot the system. You probably will
>> want to continue the boot after giving error message.
>>
>> If yes, then this area is going to need some work. Currently chao
>> is making changes where if an error occurs, then we will be isolated
>> to kdump error handler which will reboot the system.
> Yes, we will replace the default emergency.service of systemd with our own
> emergency.service.
>
> I think in case of fadump, we can simply find a way to propagate fadump
> flag from mkdumprd to dracut-module-setup, then we can skip the
> replacement and leave the default one still.
>
> W/o the replacement of emergency.service, fadump could work as expected.
>
If saving vmcore failed (after kdump service was started), will that
not invoke error handler. I am not sure if that will be kdump one or
default one. But that might not be required in fadump case.
Secondly, right now after successful dump , we reboot the machine and
fadump will not like that.
I am not sure how is it working for Hari right now. Did I miss something.
Thanks
Vivek
Vivek, currently after saving dump, we do reboot in fadump case too.
"Fadump Operational Flow" section in fadump-howto.txt summarizes the same.
In failure case, fadump also depends on existing error handling mechanism
in kexec-tools package. So, as of now, all the configuration options in
/etc/kdump.conf file apply to fadump as well.
Thanks
Hari