With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2
and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
Before:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
After:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
Signed-off-by: Prarit Bhargava prarit@redhat.com --- kdumpctl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl index ee3214a..a9e5d2e 100755 --- a/kdumpctl +++ b/kdumpctl @@ -105,7 +105,7 @@ prepare_cmdline() else cmdline=${KDUMP_COMMANDLINE} fi - cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz` + cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz panic_on_warn`
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Thanks Vivek
Before:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
After:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
Signed-off-by: Prarit Bhargava prarit@redhat.com
kdumpctl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl index ee3214a..a9e5d2e 100755 --- a/kdumpctl +++ b/kdumpctl @@ -105,7 +105,7 @@ prepare_cmdline() else cmdline=${KDUMP_COMMANDLINE} fi
- cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz panic_on_warn`
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
-- 1.7.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 11/17/2014 03:48 PM, Vivek Goyal wrote:
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
P.
Thanks Vivek
Before:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
After:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
Signed-off-by: Prarit Bhargava prarit@redhat.com
kdumpctl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl index ee3214a..a9e5d2e 100755 --- a/kdumpctl +++ b/kdumpctl @@ -105,7 +105,7 @@ prepare_cmdline() else cmdline=${KDUMP_COMMANDLINE} fi
- cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz panic_on_warn`
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
-- 1.7.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 12/16/14 at 11:23am, Prarit Bhargava wrote:
On 11/17/2014 03:48 PM, Vivek Goyal wrote:
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Thanks Prarit. I'll merge this one.
Thanks WANG Chao
P.
Thanks Vivek
Before:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
After:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
Signed-off-by: Prarit Bhargava prarit@redhat.com
kdumpctl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl index ee3214a..a9e5d2e 100755 --- a/kdumpctl +++ b/kdumpctl @@ -105,7 +105,7 @@ prepare_cmdline() else cmdline=${KDUMP_COMMANDLINE} fi
- cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz panic_on_warn`
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
-- 1.7.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 12/16/14 at 11:23am, Prarit Bhargava wrote:
On 11/17/2014 03:48 PM, Vivek Goyal wrote:
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Prarit, rethink about it. How about do something in kexec-tools c code to remove panic_on_warn for kdump kernel boot? Since it is for not only rh distribution it will save time for other people who do not notice the changes.
P.
Thanks Vivek
Before:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
After:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
Signed-off-by: Prarit Bhargava prarit@redhat.com
kdumpctl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl index ee3214a..a9e5d2e 100755 --- a/kdumpctl +++ b/kdumpctl @@ -105,7 +105,7 @@ prepare_cmdline() else cmdline=${KDUMP_COMMANDLINE} fi
- cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz panic_on_warn`
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
-- 1.7.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 12/17/14 at 04:40pm, Dave Young wrote:
On 12/16/14 at 11:23am, Prarit Bhargava wrote:
On 11/17/2014 03:48 PM, Vivek Goyal wrote:
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Prarit, rethink about it. How about do something in kexec-tools c code to remove panic_on_warn for kdump kernel boot? Since it is for not only rh distribution it will save time for other people who do not notice the changes.
We already have below: kexec-tools/kexec/kexec.c: 1055 if (kexec_flags & KEXEC_ON_CRASH) 1056 remove_parameter(line, "crashkernel");
P.
Thanks Vivek
Before:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
After:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
Signed-off-by: Prarit Bhargava prarit@redhat.com
kdumpctl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl index ee3214a..a9e5d2e 100755 --- a/kdumpctl +++ b/kdumpctl @@ -105,7 +105,7 @@ prepare_cmdline() else cmdline=${KDUMP_COMMANDLINE} fi
- cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz panic_on_warn`
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
-- 1.7.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 12/17/2014 03:45 AM, Dave Young wrote:
On 12/17/14 at 04:40pm, Dave Young wrote:
On 12/16/14 at 11:23am, Prarit Bhargava wrote:
On 11/17/2014 03:48 PM, Vivek Goyal wrote:
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Prarit, rethink about it. How about do something in kexec-tools c code to remove panic_on_warn for kdump kernel boot? Since it is for not only rh distribution it will save time for other people who do not notice the changes.
We already have below: kexec-tools/kexec/kexec.c: 1055 if (kexec_flags & KEXEC_ON_CRASH) 1056 remove_parameter(line, "crashkernel");
Ah -- I didn't even know about that. I'll look into this today and repost.
Thanks for the pointer Dave!
P.
On 12/17/14 at 04:45pm, Dave Young wrote:
On 12/17/14 at 04:40pm, Dave Young wrote:
On 12/16/14 at 11:23am, Prarit Bhargava wrote:
On 11/17/2014 03:48 PM, Vivek Goyal wrote:
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Prarit, rethink about it. How about do something in kexec-tools c code to remove panic_on_warn for kdump kernel boot? Since it is for not only rh distribution it will save time for other people who do not notice the changes.
We already have below: kexec-tools/kexec/kexec.c: 1055 if (kexec_flags & KEXEC_ON_CRASH) 1056 remove_parameter(line, "crashkernel");
I don't think so. crashkernel=X is mandatory in kernel cmdline for 1st kernel, but 2nd kernel definitely do not want it. That's why we have to remove it at any case. That's why we do it in kexec.c
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
I think it's better to do it in our kexec-tools as a distribution specific manner.
Thanks WANG Chao
P.
Thanks Vivek
Before:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
After:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+ root=/dev/mapper/rhel_intel--canoepass--05-root ro rd.lvm.lv=rhel_intel-canoepass-05/root rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81 LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=839092K
Signed-off-by: Prarit Bhargava prarit@redhat.com
kdumpctl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl index ee3214a..a9e5d2e 100755 --- a/kdumpctl +++ b/kdumpctl @@ -105,7 +105,7 @@ prepare_cmdline() else cmdline=${KDUMP_COMMANDLINE} fi
- cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz panic_on_warn`
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
-- 1.7.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 12/18/14 at 10:34am, WANG Chao wrote:
On 12/17/14 at 04:45pm, Dave Young wrote:
On 12/17/14 at 04:40pm, Dave Young wrote:
On 12/16/14 at 11:23am, Prarit Bhargava wrote:
On 11/17/2014 03:48 PM, Vivek Goyal wrote:
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote:
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2and which is now staged in Andrew Morton's tree, we need to remove 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Prarit, rethink about it. How about do something in kexec-tools c code to remove panic_on_warn for kdump kernel boot? Since it is for not only rh distribution it will save time for other people who do not notice the changes.
We already have below: kexec-tools/kexec/kexec.c: 1055 if (kexec_flags & KEXEC_ON_CRASH) 1056 remove_parameter(line, "crashkernel");
I don't think so. crashkernel=X is mandatory in kernel cmdline for 1st kernel, but 2nd kernel definitely do not want it. That's why we have to remove it at any case. That's why we do it in kexec.c
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
IMHO panic_on_warn is useless in 2nd kernel, it will cause vmcore capture failed due to some minor issues which can be ignored. It is harmful actually, if one forget to remove it in 2nd kernel cmdline he maybe has never chance to redo it again because bugs are not easily reproduced sometimes.
You mentioned one can use it by purpose, but it can not convince me,
head-scratching :)
I think it's better to do it in our kexec-tools as a distribution specific manner.
Do it in distribution is good, but I do like it in upstream.
Thanks Dave
On 12/19/14 at 12:40pm, Dave Young wrote:
On 12/18/14 at 10:34am, WANG Chao wrote:
On 12/17/14 at 04:45pm, Dave Young wrote:
On 12/17/14 at 04:40pm, Dave Young wrote:
On 12/16/14 at 11:23am, Prarit Bhargava wrote:
On 11/17/2014 03:48 PM, Vivek Goyal wrote:
On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote: > With the inclusion of 'panic_on_warn', > > http://marc.info/?l=linux-api&m=141570937328528&w=2 > > and which is now staged in Andrew Morton's tree, we need to remove > 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is > possible a non-fatal warning could panic the second kernel.
This patch looks good to me. I think we can commit it once it show up in Linus tree.
Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Prarit, rethink about it. How about do something in kexec-tools c code to remove panic_on_warn for kdump kernel boot? Since it is for not only rh distribution it will save time for other people who do not notice the changes.
We already have below: kexec-tools/kexec/kexec.c: 1055 if (kexec_flags & KEXEC_ON_CRASH) 1056 remove_parameter(line, "crashkernel");
I don't think so. crashkernel=X is mandatory in kernel cmdline for 1st kernel, but 2nd kernel definitely do not want it. That's why we have to remove it at any case. That's why we do it in kexec.c
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
IMHO panic_on_warn is useless in 2nd kernel, it will cause vmcore capture failed due to some minor issues which can be ignored. It is harmful actually, if one forget to remove it in 2nd kernel cmdline he maybe has never chance to redo it again because bugs are not easily reproduced sometimes.
You mentioned one can use it by purpose, but it can not convince me,
If removing panic_on_warn in kexec.c, user won't have a chance to put this option to 2nd kernel. But if removing it in kexec-tools script, user still have a chance to add it in KDUMP_CMDLINE_APPEND of /etc/sysconfig/kdump.
Thanks WANG Chao
On 12/19/14 at 12:48pm, WANG Chao wrote:
On 12/19/14 at 12:40pm, Dave Young wrote:
On 12/18/14 at 10:34am, WANG Chao wrote:
On 12/17/14 at 04:45pm, Dave Young wrote:
On 12/17/14 at 04:40pm, Dave Young wrote:
On 12/16/14 at 11:23am, Prarit Bhargava wrote:
On 11/17/2014 03:48 PM, Vivek Goyal wrote: > On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote: >> With the inclusion of 'panic_on_warn', >> >> http://marc.info/?l=linux-api&m=141570937328528&w=2 >> >> and which is now staged in Andrew Morton's tree, we need to remove >> 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is >> possible a non-fatal warning could panic the second kernel. > > This patch looks good to me. I think we can commit it once it show > up in Linus tree. > > Acked-by: Vivek Goyal vgoyal@redhat.com
Dave and Vivek (who is on PTO),
The panic_on_warn patch has been committed into linux.git as 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Prarit, rethink about it. How about do something in kexec-tools c code to remove panic_on_warn for kdump kernel boot? Since it is for not only rh distribution it will save time for other people who do not notice the changes.
We already have below: kexec-tools/kexec/kexec.c: 1055 if (kexec_flags & KEXEC_ON_CRASH) 1056 remove_parameter(line, "crashkernel");
I don't think so. crashkernel=X is mandatory in kernel cmdline for 1st kernel, but 2nd kernel definitely do not want it. That's why we have to remove it at any case. That's why we do it in kexec.c
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
IMHO panic_on_warn is useless in 2nd kernel, it will cause vmcore capture failed due to some minor issues which can be ignored. It is harmful actually, if one forget to remove it in 2nd kernel cmdline he maybe has never chance to redo it again because bugs are not easily reproduced sometimes.
You mentioned one can use it by purpose, but it can not convince me,
If removing panic_on_warn in kexec.c, user won't have a chance to put this option to 2nd kernel. But if removing it in kexec-tools script, user still have a chance to add it in KDUMP_CMDLINE_APPEND of /etc/sysconfig/kdump.
Problem is if there's a case panic_on_warn is useful for 2nd kernel. Let's see what's the opinion from other people, since this can be specified in our kdump sysconfig file, anyway it is not a big issue.
Thanks Dave
On 12/19/14 at 03:02pm, Dave Young wrote:
On 12/19/14 at 12:48pm, WANG Chao wrote:
On 12/19/14 at 12:40pm, Dave Young wrote:
On 12/18/14 at 10:34am, WANG Chao wrote:
On 12/17/14 at 04:45pm, Dave Young wrote:
On 12/17/14 at 04:40pm, Dave Young wrote:
On 12/16/14 at 11:23am, Prarit Bhargava wrote: > > > On 11/17/2014 03:48 PM, Vivek Goyal wrote: > > On Mon, Nov 17, 2014 at 11:13:50AM -0500, Prarit Bhargava wrote: > >> With the inclusion of 'panic_on_warn', > >> > >> http://marc.info/?l=linux-api&m=141570937328528&w=2 > >> > >> and which is now staged in Andrew Morton's tree, we need to remove > >> 'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is > >> possible a non-fatal warning could panic the second kernel. > > > > This patch looks good to me. I think we can commit it once it show > > up in Linus tree. > > > > Acked-by: Vivek Goyal vgoyal@redhat.com > > Dave and Vivek (who is on PTO), > > The panic_on_warn patch has been committed into linux.git as > 9e3961a0979817c612b10b2da4f3045ec9faa779 ("kernel: add panic_on_warn").
Prarit, rethink about it. How about do something in kexec-tools c code to remove panic_on_warn for kdump kernel boot? Since it is for not only rh distribution it will save time for other people who do not notice the changes.
We already have below: kexec-tools/kexec/kexec.c: 1055 if (kexec_flags & KEXEC_ON_CRASH) 1056 remove_parameter(line, "crashkernel");
I don't think so. crashkernel=X is mandatory in kernel cmdline for 1st kernel, but 2nd kernel definitely do not want it. That's why we have to remove it at any case. That's why we do it in kexec.c
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
IMHO panic_on_warn is useless in 2nd kernel, it will cause vmcore capture failed due to some minor issues which can be ignored. It is harmful actually, if one forget to remove it in 2nd kernel cmdline he maybe has never chance to redo it again because bugs are not easily reproduced sometimes.
You mentioned one can use it by purpose, but it can not convince me,
If removing panic_on_warn in kexec.c, user won't have a chance to put this option to 2nd kernel. But if removing it in kexec-tools script, user still have a chance to add it in KDUMP_CMDLINE_APPEND of /etc/sysconfig/kdump.
Problem is if there's a case panic_on_warn is useful for 2nd kernel. Let's see what's the opinion from other people, since this can be specified in our kdump sysconfig file, anyway it is not a big issue.
If removal happens in kexec.c level, then there's no way to add panic_on_warn to 2nd kernel.
I agree it's not a big issue. Let's wait and see.
Thanks WANG Chao
Problem is if there's a case panic_on_warn is useful for 2nd kernel. Let's see what's the opinion from other people, since this can be specified in our kdump sysconfig file, anyway it is not a big issue.
If removal happens in kexec.c level, then there's no way to add panic_on_warn to 2nd kernel.
I agree it's not a big issue. Let's wait and see.
Just thinking this through. Suppose someone did want panic_on_warn on the second kernel.
1. The 2nd kernel would stop booting and kdump would fail. 2. The _only_ difference in the stack trace is that we panic vs WARN. That is, if panic_on_warn is not specified you would still have the same amount of information on the 2nd kernel.
So I think there is no advantage to adding panic_on_warn to the 2nd kernel.
P.
Thanks WANG Chao
On Fri, Dec 19, 2014 at 12:40:36PM +0800, Dave Young wrote:
[..]
I think it's better to do it in our kexec-tools as a distribution specific manner.
Do it in distribution is good, but I do like it in upstream.
Dave,
In the past we have burnt fingers with doing lot of command line specific magic in kexec-tools. I think there were conflicts w.r.t efi parameters when kexec-tools is used on different kernels.
At that point of time lesson we learnt that don't do command line handling in kexec-tools (until and unless it is necessary) and it is better to let distribution specific scripts do it.
Thanks Vivek
On Thu, Dec 18, 2014 at 10:34:42AM +0800, WANG Chao wrote:
[..]
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
I think it's better to do it in our kexec-tools as a distribution specific manner.
Agreed. Distribution specific scripts should be a better place for this kind of change instead of modifying kexec-tools. kexec-tools should have no business deciding whether panic_on_warn makes sense in second kernel or not.
Thanks Vivek
On 01/02/15 at 08:45am, Vivek Goyal wrote:
On Thu, Dec 18, 2014 at 10:34:42AM +0800, WANG Chao wrote:
[..]
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
I think it's better to do it in our kexec-tools as a distribution specific manner.
Agreed. Distribution specific scripts should be a better place for this kind of change instead of modifying kexec-tools. kexec-tools should have no business deciding whether panic_on_warn makes sense in second kernel or not.
Yeah, most likely. But panic_on_warn is a little special then on this issue. panic_on_warn is not the stuff which doesn't hurt 2nd kernel, it surely does. I can't imagine any motivation someone expect a panic_on_warn action in kdump kernel.
That means removing panic_on_warn whould be a common requirement, no matter what distribution. On this point it's suitable to remove it in kexec.
Thanks Baoquan
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On Sun, Jan 04, 2015 at 10:54:26AM +0800, Baoquan He wrote:
On 01/02/15 at 08:45am, Vivek Goyal wrote:
On Thu, Dec 18, 2014 at 10:34:42AM +0800, WANG Chao wrote:
[..]
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
I think it's better to do it in our kexec-tools as a distribution specific manner.
Agreed. Distribution specific scripts should be a better place for this kind of change instead of modifying kexec-tools. kexec-tools should have no business deciding whether panic_on_warn makes sense in second kernel or not.
Yeah, most likely. But panic_on_warn is a little special then on this issue. panic_on_warn is not the stuff which doesn't hurt 2nd kernel, it surely does. I can't imagine any motivation someone expect a panic_on_warn action in kdump kernel.
I gave one corner case example where due to some bug fs corruption happens after warning if we continue. In that case panic_on_warn will make sense even in second kernel as a workaround.
Secondly, kernel will keep on introducing new command line parameters and some of them will not make sense in second kenrel. It should not be kexec-tools responsibility to figure out which of these parameters make sense and which one should be removed. It is the responsibility of distribution specific scripts.
Some of these parameters might be hidden behind CONFIG_OO option and while one distribution might have to remove it, other might not have to do the same thing (depending on whether CONFIG_FOO was enabled or not).
So I do think that kexec-tools should not get into the business of removing parameters from kernel command line. It should pass it to second kernel as passed in by user. Rest of the magic should take place in distribution specific scripts as needed.
Thanks Vivek
-
Baoquan He -
Dave Young -
Prarit Bhargava -
Vivek Goyal -
WANG Chao