This bug was fixed in the package makedumpfile -
1:1.6.5-1ubuntu1~18.04.3
---------------
makedumpfile (1:1.6.5-1ubuntu1~18.04.3) bionic; urgency=medium
[ Guilherme G. Piccoli ]
* Add kdump retry/delay mechanism when dumping over network (LP: #1681909)
[ Thadeu Lima de Souza Cascardo ]
* Use maxcpus instead of nr_cpus on ppc64el. (LP: #1828597)
* ppc64: increase MAX_PHYSMEM_BITS to 2PB (LP: #1841288)
[ Connor Kuehl ]
* Let the kernel decide the crashkernel offset for ppc64el (LP: #1741860)
-- Thadeu Lima de Souza Cascardo <casca...@canonical.com> Wed, 09 Oct
2019 15:38:08 -0300
** Changed in: makedumpfile (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1828597
Title:
KDump boot fails with nr_cpus=1
Status in The Ubuntu-power-systems project:
Fix Committed
Status in kexec-tools package in Ubuntu:
Invalid
Status in linux package in Ubuntu:
Invalid
Status in makedumpfile package in Ubuntu:
Fix Released
Status in makedumpfile source package in Bionic:
Fix Released
Status in kexec-tools source package in Cosmic:
Invalid
Status in kexec-tools source package in Disco:
Invalid
Status in linux source package in Disco:
Invalid
Status in makedumpfile source package in Disco:
Fix Released
Status in kexec-tools source package in Eoan:
Invalid
Status in linux source package in Eoan:
Invalid
Status in makedumpfile source package in Eoan:
Fix Released
Bug description:
[Impact]
The kdump kernel will crash during its boot if booted on a CPU other than 0.
[Test case]
Trigger a crash using taskset -c X, where X is not 0 and is a present CPU.
Check that the dump is successful.
echo c | sudo taskset -c 1 tee /proc/sysrq-trigger
[Regression potential]
This will cause more memory to be used by the dump kernel, which may cause
OOMs during the dump. The fix is restricted to ppc64el.
== Comment: #0 - Hari Krishna Bathini - 2019-05-10 06:38:21 ==
---Problem Description---
kdump boots fails in some environments when nr_cpus=1 is passed
---uname output---
na
Machine Type = na
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1. configure kdump
2. trigger crash on non-boot cpu
Expected result:
Capture dump and reboot
Actual result:
Hang in early kdump boot process after crash
Userspace tool common name: kdump-tools
The userspace tool has the following bit modes: 64-bit
Userspace rpm: kdump-tools
Userspace tool obtained from project website: na
== Comment: #1 - Hari Krishna Bathini - 2019-05-10 06:45:46 ==
Launchpad bug 1560552 added "nr_cpus=1" support on ppc64 though
this change never made it upstream as maintainer has a few apprehensions..
With 4.18 kernels, this change is dropped on Ubuntu kernels too.
With nr_cpus=1 support in kernel, kdump-tools was also updated to
use "nr_cpsu=1" by default instead of "maxcpus=1" (see launchpad
bug 1568952). This kdump-tools change has to be reverted to make
it consist with the kernel change. Note that "nr_cpus=1 change had
a issues in kdump guest environment even with "nr_cpus=1" support
for kdump in kernel. So, even not withstanding the kernel revert, it is
better to default to "maxcpus=1" on all kernel versions. So, please
revert the kdump-tools fix that went in with launchpad bug 1568952
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1828597/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
