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.org/...
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