When watchdog is enabled in 1st kernel, then crash dump in kdump kernel will be interrupted if watchdog is timeout. Since some wdt drivers can stop the watchdog when its driver is loaded, e.g iTCO_wdt, this can benefit crash dump.
Add watchdog driver which is active in system to initramfs, its loading can stop watchdog.
For now, put this adding in 99kdumpbase.
Signed-off-by: Baoquan He bhe@redhat.com --- dracut-module-setup.sh | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..d1ba83e 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -418,3 +418,11 @@ install() { # at some point of time. kdump_check_iscsi_targets } + +installkernel() { + wdt=$(lsmod|cut -f1 -d' '|grep "wdt$") + if [ -n "$wdt" ]; then + instmods $wdt + [ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich + fi +}
Hi Vivek,
Finally we agreed to add wdt driver to 99kdumpbase for the time being, so how do you think about this patch, is it OK to you?
Baoquan Thanks
On 01/23/14 at 02:09pm, Baoquan He wrote:
When watchdog is enabled in 1st kernel, then crash dump in kdump kernel will be interrupted if watchdog is timeout. Since some wdt drivers can stop the watchdog when its driver is loaded, e.g iTCO_wdt, this can benefit crash dump.
Add watchdog driver which is active in system to initramfs, its loading can stop watchdog.
For now, put this adding in 99kdumpbase.
Signed-off-by: Baoquan He bhe@redhat.com
dracut-module-setup.sh | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..d1ba83e 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -418,3 +418,11 @@ install() { # at some point of time. kdump_check_iscsi_targets }
+installkernel() {
- wdt=$(lsmod|cut -f1 -d' '|grep "wdt$")
- if [ -n "$wdt" ]; then
instmods $wdt[ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich- fi
+}
1.8.3.1
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On Thu, Jan 23, 2014 at 02:09:46PM +0800, Baoquan He wrote:
When watchdog is enabled in 1st kernel, then crash dump in kdump kernel will be interrupted if watchdog is timeout. Since some wdt drivers can stop the watchdog when its driver is loaded, e.g iTCO_wdt, this can benefit crash dump.
Add watchdog driver which is active in system to initramfs, its loading can stop watchdog.
For now, put this adding in 99kdumpbase.
Signed-off-by: Baoquan He bhe@redhat.com
dracut-module-setup.sh | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..d1ba83e 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -418,3 +418,11 @@ install() { # at some point of time. kdump_check_iscsi_targets }
+installkernel() {
- wdt=$(lsmod|cut -f1 -d' '|grep "wdt$")
- if [ -n "$wdt" ]; then
instmods $wdt[ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich- fi
+}
Hi Bao,
This patch looks good to me.
Acked-by: Vivek Goyal vgoyal@redhat.com
I am also CCing Don Zickus.
I think driver inclusion in initramfs is is first good step towards solving watchdog related issues. Next step will be to setup appropriate timeout values and setup systemd right kick intervals and make sure kicking starts again in second kernel.
I am curious what is lpc_ich? If this is a dependeny, shouldn't module express it and it should automatically be pulled in by dracut.
Thanks Vivek
On Wed, Feb 12, 2014 at 04:15:13PM -0500, Vivek Goyal wrote:
On Thu, Jan 23, 2014 at 02:09:46PM +0800, Baoquan He wrote:
When watchdog is enabled in 1st kernel, then crash dump in kdump kernel will be interrupted if watchdog is timeout. Since some wdt drivers can stop the watchdog when its driver is loaded, e.g iTCO_wdt, this can benefit crash dump.
Add watchdog driver which is active in system to initramfs, its loading can stop watchdog.
For now, put this adding in 99kdumpbase.
Signed-off-by: Baoquan He bhe@redhat.com
dracut-module-setup.sh | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..d1ba83e 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -418,3 +418,11 @@ install() { # at some point of time. kdump_check_iscsi_targets }
+installkernel() {
- wdt=$(lsmod|cut -f1 -d' '|grep "wdt$")
- if [ -n "$wdt" ]; then
instmods $wdt[ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich- fi
+}
Hi Bao,
This patch looks good to me.
Acked-by: Vivek Goyal vgoyal@redhat.com
I am also CCing Don Zickus.
I think driver inclusion in initramfs is is first good step towards solving watchdog related issues. Next step will be to setup appropriate timeout values and setup systemd right kick intervals and make sure kicking starts again in second kernel.
I am curious what is lpc_ich? If this is a dependeny, shouldn't module express it and it should automatically be pulled in by dracut.
No. lpc_ich attaches to the hardware and creates platform devices based on what intel chipset is found. So if the intel chipset has a iTCO watchdog, then that device is virtually created on the platform bus, the bus probe routine discovers it and sends a message to udev to load that module.
Not quite an explicit dependency. And from the iTCO perspective, I think it can load on older intel chipsets without an lcp_ich driver. So again, not a dependency you can really rely on.
This seems to be the right approach, on boot the right modules will load.
Cheers, Don
On Wed, Feb 12, 2014 at 04:35:55PM -0500, Don Zickus wrote:
On Wed, Feb 12, 2014 at 04:15:13PM -0500, Vivek Goyal wrote:
On Thu, Jan 23, 2014 at 02:09:46PM +0800, Baoquan He wrote:
When watchdog is enabled in 1st kernel, then crash dump in kdump kernel will be interrupted if watchdog is timeout. Since some wdt drivers can stop the watchdog when its driver is loaded, e.g iTCO_wdt, this can benefit crash dump.
Add watchdog driver which is active in system to initramfs, its loading can stop watchdog.
For now, put this adding in 99kdumpbase.
Signed-off-by: Baoquan He bhe@redhat.com
dracut-module-setup.sh | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..d1ba83e 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -418,3 +418,11 @@ install() { # at some point of time. kdump_check_iscsi_targets }
+installkernel() {
- wdt=$(lsmod|cut -f1 -d' '|grep "wdt$")
- if [ -n "$wdt" ]; then
instmods $wdt[ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich- fi
+}
Hi Bao,
This patch looks good to me.
Acked-by: Vivek Goyal vgoyal@redhat.com
I am also CCing Don Zickus.
I think driver inclusion in initramfs is is first good step towards solving watchdog related issues. Next step will be to setup appropriate timeout values and setup systemd right kick intervals and make sure kicking starts again in second kernel.
I am curious what is lpc_ich? If this is a dependeny, shouldn't module express it and it should automatically be pulled in by dracut.
No. lpc_ich attaches to the hardware and creates platform devices based on what intel chipset is found. So if the intel chipset has a iTCO watchdog, then that device is virtually created on the platform bus, the bus probe routine discovers it and sends a message to udev to load that module.
Not quite an explicit dependency. And from the iTCO perspective, I think it can load on older intel chipsets without an lcp_ich driver. So again, not a dependency you can really rely on.
So who is supposed to pull in lpc_ich? Does dracut by default not inclue lpc_ich driver if need be?
Thanks Vivek
On 02/12/14 at 04:39pm, Vivek Goyal wrote:
On Wed, Feb 12, 2014 at 04:35:55PM -0500, Don Zickus wrote:
On Wed, Feb 12, 2014 at 04:15:13PM -0500, Vivek Goyal wrote:
On Thu, Jan 23, 2014 at 02:09:46PM +0800, Baoquan He wrote:
When watchdog is enabled in 1st kernel, then crash dump in kdump kernel will be interrupted if watchdog is timeout. Since some wdt drivers can stop the watchdog when its driver is loaded, e.g iTCO_wdt, this can benefit crash dump.
Add watchdog driver which is active in system to initramfs, its loading can stop watchdog.
For now, put this adding in 99kdumpbase.
Signed-off-by: Baoquan He bhe@redhat.com
dracut-module-setup.sh | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..d1ba83e 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -418,3 +418,11 @@ install() { # at some point of time. kdump_check_iscsi_targets }
+installkernel() {
- wdt=$(lsmod|cut -f1 -d' '|grep "wdt$")
- if [ -n "$wdt" ]; then
instmods $wdt[ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich- fi
+}
Hi Bao,
This patch looks good to me.
Acked-by: Vivek Goyal vgoyal@redhat.com
I am also CCing Don Zickus.
I think driver inclusion in initramfs is is first good step towards solving watchdog related issues. Next step will be to setup appropriate timeout values and setup systemd right kick intervals and make sure kicking starts again in second kernel.
I am curious what is lpc_ich? If this is a dependeny, shouldn't module express it and it should automatically be pulled in by dracut.
No. lpc_ich attaches to the hardware and creates platform devices based on what intel chipset is found. So if the intel chipset has a iTCO watchdog, then that device is virtually created on the platform bus, the bus probe routine discovers it and sends a message to udev to load that module.
Not quite an explicit dependency. And from the iTCO perspective, I think it can load on older intel chipsets without an lcp_ich driver. So again, not a dependency you can really rely on.
So who is supposed to pull in lpc_ich? Does dracut by default not inclue lpc_ich driver if need be?
dracut use modprobe with option "--show-depends" to list all depends of one kernel module. That option relies on /lib/module/{kernel-release}/modules.dep. In rhel6 we directly check it in this file.
However iTCO_wdt doesn't have depends on lpc_ich in /lib/module/{kernel-release}/modules.dep though it truly depends on lpc_ich on implementation. Obviously dracut can't do anything on this. iTCO_wdt is special and unique here, handling it specifically is needed.
Baoquan Thanks
Thanks Vivek
On Wed, Feb 12, 2014 at 04:39:05PM -0500, Vivek Goyal wrote:
I am curious what is lpc_ich? If this is a dependeny, shouldn't module express it and it should automatically be pulled in by dracut.
No. lpc_ich attaches to the hardware and creates platform devices based on what intel chipset is found. So if the intel chipset has a iTCO watchdog, then that device is virtually created on the platform bus, the bus probe routine discovers it and sends a message to udev to load that module.
Not quite an explicit dependency. And from the iTCO perspective, I think it can load on older intel chipsets without an lcp_ich driver. So again, not a dependency you can really rely on.
So who is supposed to pull in lpc_ich? Does dracut by default not inclue lpc_ich driver if need be?
Why does dracut need to pull in lpc_ich, it normally isn't needed for booting. When the disk is mounted, udev re-does the probing I think and picks up the new device event.
Kdump is special here.
Cheers, Don
On Thu, Feb 13, 2014 at 08:59:29AM -0500, Don Zickus wrote:
On Wed, Feb 12, 2014 at 04:39:05PM -0500, Vivek Goyal wrote:
I am curious what is lpc_ich? If this is a dependeny, shouldn't module express it and it should automatically be pulled in by dracut.
No. lpc_ich attaches to the hardware and creates platform devices based on what intel chipset is found. So if the intel chipset has a iTCO watchdog, then that device is virtually created on the platform bus, the bus probe routine discovers it and sends a message to udev to load that module.
Not quite an explicit dependency. And from the iTCO perspective, I think it can load on older intel chipsets without an lcp_ich driver. So again, not a dependency you can really rely on.
So who is supposed to pull in lpc_ich? Does dracut by default not inclue lpc_ich driver if need be?
Why does dracut need to pull in lpc_ich, it normally isn't needed for booting. When the disk is mounted, udev re-does the probing I think and picks up the new device event.
Kdump is special here.
I think dracut should enable watchdog in general. Reason being that if BIOS has enabled the watchdog then you probably want the watchdog driver to load early and user space should start kicking watchdog.
Think of dropping to shell for dracut debugging. I guess we wouldn't want to be pulled down by watchdog because we did not mount root fast enough.
Well, that's a separate discussion I guess as harald does not seem to be convinced yet about watchdog in dracut.
Anyhow, I agree that in current form dracut might not have to worry about lpc_ich. So this patch is fine. Things can probably be improved down the line.
Thanks Vivek
On Thu, Feb 13, 2014 at 09:12:35AM -0500, Vivek Goyal wrote:
On Thu, Feb 13, 2014 at 08:59:29AM -0500, Don Zickus wrote:
On Wed, Feb 12, 2014 at 04:39:05PM -0500, Vivek Goyal wrote:
I am curious what is lpc_ich? If this is a dependeny, shouldn't module express it and it should automatically be pulled in by dracut.
No. lpc_ich attaches to the hardware and creates platform devices based on what intel chipset is found. So if the intel chipset has a iTCO watchdog, then that device is virtually created on the platform bus, the bus probe routine discovers it and sends a message to udev to load that module.
Not quite an explicit dependency. And from the iTCO perspective, I think it can load on older intel chipsets without an lcp_ich driver. So again, not a dependency you can really rely on.
So who is supposed to pull in lpc_ich? Does dracut by default not inclue lpc_ich driver if need be?
Why does dracut need to pull in lpc_ich, it normally isn't needed for booting. When the disk is mounted, udev re-does the probing I think and picks up the new device event.
Kdump is special here.
I think dracut should enable watchdog in general. Reason being that if BIOS has enabled the watchdog then you probably want the watchdog driver to load early and user space should start kicking watchdog.
Think of dropping to shell for dracut debugging. I guess we wouldn't want to be pulled down by watchdog because we did not mount root fast enough.
I look at patches like that as 'as-needed'. If Harold isn't seeing to many bugzillas whining about this, then I doubt he is motivated to fix a 'theoretical' problem.
I can't argue about keeping the initramfs small (it is too bloated anyway). :-)
Well, that's a separate discussion I guess as harald does not seem to be convinced yet about watchdog in dracut.
Well, kdump gets to lead here. If it becomes a problem Harold knows what code to copy-n-paste. ;-p
Cheers, Don
-
Baoquan He -
Don Zickus -
Vivek Goyal