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