Hi, Pratyush
On 02/22/16 at 05:59pm, Pratyush Anand wrote:
Hi Dave,
On 19/02/2016:08:00:23 PM, Dave Young wrote:
> Hi, Pratyush
>
> Ccing harald for dracut discussion
>
> On 02/18/16 at 09:02pm, Pratyush Anand wrote:
> > Hi Dave,
> >
> > Thanks for your review and inputs.
> >
> > On 18/02/2016:08:44:25 PM, Dave Young wrote:
> > >
> > > I have several thing to make clear:
> > >
> > > * Previously we tried to add it as a dracut module in upstream dracut.
> > >
https://www.mail-archive.com/initramfs@vger.kernel.org/msg03299.html
> > > In dracut there is a simple watchdog module which is used for testing
purpose
> > > only.
> > > We have a reliable way to get hostonly live watchdog module based on your
> > > kernel patches, so it might be better to retry to enhance the dracut
watchdog
> > > module. Kdump use dracut --hostonly, we can add using wdt module for
hostonly
> > > mode. In this way we can add another dracut kernel cmdline like rd.nowdt
so
> > > that one can disable wdt functionality in initramfs if he/she want the
original
> > > behavior.
> >
> > Its a good idea for implementing a switch, which will help to insert or not to
insert
> > active wdt module in kdump kernel. Since, I do not have much idea about
dracut,
> > so to understand it better for implementation perspective:
> > - user can pass rd.nowdt through KDUMP_COMMANDLINE_APPEND of
> > /etc/sysconfig/kdump
>
> Right
>
> > - We will have an upstream dracut change, which will check that if rd.nowdt
was
> > *not* passed in command line then, add modules from rd.driver.pre.
>
> I meant about moving patch 1/2 to dracut, not only about the new param.
If I understood it correctly:
- a dracut service (04watchdog) will check if it is --host-only mode
- if yes, then it will check if it is !rd.nowdt
- if yes, then update rd.driver.pre with the active wdt module name (as we are
doing in this patch).
@Herald: Please let me know your opinion about above proposed changes in
upstream dracut.
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.
>
> Dracut git is here:
>
git://git.kernel.org/pub/scm/boot/dracut/dracut.git
>
> There already a dracut module named 04watchdog, see dracut/modules.d/04watchdog
>
> But it is used as test only for now. It might need more investigation if we can
Sure, will do some experiment to verify the possibility.
> add code into the module. In 04watchdog it does not use systemd also it hardcode
> to load modules like below:
> modprobe ib700wdt
> modprobe i6300esb
I think that hardcode part will still remain as it is. We need to make changes
only when /dev/watchdog exist.
>
> >
> > >
> > > * Previously we planned to only enabling wdt when driver initialization
can not
> > > stop wdt eg. in 2nd kernel the wdt status is active after insmod. But if
we
> > > copy systemd.conf from 1st kernel to initrd, it will by default enable
the
> > > wdt. Do you think it is a better way? Maybe it can address the concern
from
> > > Prarit?
> >
> > I think, its better to keep same state of wdt what was in primary kernel (if
> > rd.nowdt was not passed). I am not sure if we need to implement systemd.conf
> > copy, I think that is already done currently. Both on fedora and RHEL as you
can
> > see in commit log, wdt is active in kdump kernel if it was active in primary
> > kernel.
>
> What I meant is want to know if it is a new design while working on the patch.
> though It sounds reasonable as well.
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.
>
> systemd dracut module will copy system.conf, it is exactly the reason why it is
> active in 2nd kernel. If nobody copied it then for iTCO_wdt the state should not
> be active because driver will disable it during module init.
Yes, exactly.
>
> According our previous discuss we will load the wdt driver, only kick it when
> driver can not disable it. For example drop the wdt setup in system.conf in
> kdump kernel, if the state is still active after insmod then we will enable
> it and kick wdt.
Yes, so this is what I did not put ( drop the wdt setup in system.conf in kdump
kernel) and it was a mistake. But, now with second thought it seems more
appealing in current form, as I do not see any side effect, rather I see an
advantage of enabled watchdog in kdump kernel.
>
> 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.
>
> >
> > > > kdump:/# cat /sys/class/watchdog/watchdog0/state
> > > > active
> >
> > >
> > > * What if in 1st kernel one do not use systemd as wdt daemon? Then in 2nd
> > > kernel the behavior will be just like what we planned, insmod, driver stop
the
> > > wdt, but still need kick it when driver failed to stop the wdt?
> >
> > If it is not systemd and a custom wdt application, then I think user will need
> > to pass name of the application in /etc/kdump.conf:extra_bins and the kick
> > command in /etc/kdump.conf:kdump_pre.
>
> Ok, it make sense, but we need tell user that when we add the wdt into initrd.
Yes..that we need to document.
Thanks for your feedback.
~Pratyush
Thanks
Dave