On 02/19/16 at 08:00pm, Dave Young wrote:
Hi, Pratyush
Ccing harald for dracut discussion
Seems the code part was dropped
Here is the thread for Harald to get the details:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o...
There were some kernel patches for us to get the right kernel modules
from wdt device being used.
http://www.spinics.net/lists/linux-watchdog/msg07294.html
http://www.spinics.net/lists/linux-watchdog/msg07282.html
>
> 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.
>
> 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
> add code into the module. In 04watchdog it does not use systemd also it hardcode
> to load modules like below:
> modprobe ib700wdt
> modprobe i6300esb
>
> >
> > >
> > > * 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.
>
> 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.
>
> 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.
>
> 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?
>
> >
> > > > 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.
>
> Thanks
> Dave