On 02/24/16 at 08:31pm, Pratyush Anand wrote:
Hi Dave,
On 23/02/2016:09:14:10 AM, Dave Young wrote:
> Hi, Pratyush
>
> On 02/22/16 at 05:59pm, Pratyush Anand wrote:
> > Also, does --host-only mode used by any other application than kdump? If yes,
> > then should it be wise to keep same implementation for them as well? If not,
> > then how can we detect that it is kdump who is using dracut?
>
> --hostonly is a general option which is not only for kdump, that is why I think
> we should do it in dracut. It may make sense to add hostonly wdt logic so that
> it will help kexec reboot.
Lets say we have another application (non kdump) which creates an initramfs with
`dracut --host-only`. So what I wanted to confirm here that, with proposed
implementation initramfs of that non-kdump application will also load drivers
for active watchdog. Will that be acceptable to other applications?
Hostonly means packing things useful for the current host only so that I think for
each dracut module we can check current used setup and do same in initramfs.
Though we have systemd supporting watchdog, but if kernel hangs in initramfs phase
it will be useless because we do not add watchdog drivers in initrd. So I think it
is also useful to 1st kernel normal boot.
For people who do not want it we can add a cmdline param to disable the behavior.
>
> >
> >
> > Well, I did not made any change in design of this patch. It seems that systemd
> > is behaving like that. Then, it seemed more reasonable to me as well, because
in
> > this way we can also get benefit of watchdog in kdump kernel. If something
goes
> > wrong during dump process then watchdog will restart the machine (if it was
> > active in primary kernel as well).
> >
>
> Thanks, I agree that current approatch in the patchset is good enough.
Thanks :-)
>
> > >
> > > One case is like we talked before if wdt driver failed to disable the wdt
then
> > > it will still be active, then does systemd still work as expected?
> >
> > OK, I will get back on this soon.
I did some change in iTCO_wdt.c's probe to not to stop wdt specifically. Kicked
watchdog, restarted kdump and crashed the system. I made kdump kernel to stop at
dracut and then waited for sufficient time, but did not see system rebooting
with watchdog, so it seems that some other operation in probe caused to stop
watchdog. So, that exact situation what you were suggesting is difficult to
reproduce (atleast) with iTCO.
We need to keep it in mind, since it is not reproducible I think we can leave
it as is and address problems in the future if we have.
However, I am wondering, why would any driver not insure that wdt is
stopped
specifically. If it is left started by any chance then, won't it be an unstable
situation where system could reset before an application start kicking it's wdt.
So, in my understanding if a watchdog is not specifically stopping it in probe()
then, its a bug in the driver which need to be fixed.
I'm not sure if it is a bug, Don may have more thoughts about it.
Thanks
Dave