This bug was fixed in the package makedumpfile - 1:1.6.1-2ubuntu0.1
---------------
makedumpfile (1:1.6.1-2ubuntu0.1) artful; urgency=medium
* KDUMP_CMDLINE_APPEND: add noirqdistrib to default command line. As it's
only used by ppc64el, it's not required to be conditionally added.
(LP: #1658733)
* Set crashkernel for ppc64el to load at 128M instead of 32M. That allows
larger kernels to boot. (LP: #1728115)
-- Thadeu Lima de Souza Cascardo <casca...@canonical.com> Tue, 07 Nov
2017 12:23:33 +0000
** Changed in: makedumpfile (Ubuntu Artful)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1728115
Title:
crashkernel offset prevents kernel boot
Status in linux package in Ubuntu:
Incomplete
Status in makedumpfile package in Ubuntu:
Fix Released
Status in linux source package in Artful:
New
Status in makedumpfile source package in Artful:
Fix Released
Status in linux source package in Bionic:
Incomplete
Status in makedumpfile source package in Bionic:
Fix Released
Bug description:
[Impact]
On Power Systems, the kernel won't boot when given a crashkernel parameter
with an offset/start address of 32M. No output will be shown, giving no clue to
the user why the system has not booted, or what the problem is.
[Test Case]
Installing kdump-tools on artful, then booting the system. It won't boot.
With the fix, it boots and the crash kernel is reserved.
[Regression Potential]
Some Power Systems might have problems loading the kernel at this address.
LP#1567539 is not really clear if PowerNV systems won't kdump when using an
address different from 32M. However, it has been requested from an IBM person
to test it with 128M instead, and no particular problem was shown. It's
possible that there was no reason at first to use 32M, and no problems will be
found on either PowerNV or other systems on the field. On the other hand, it's
possible they might break kdump. But, right now, those systems won't even boot
the first kernel without this change.
----
The linux kernel won't boot when crashkernel parameter tells it to
load a crash kernel at 32Mi on ppc64el on artful.
This happens because the artful kernel is too big. In fact, multiple
requirements on the architecture lead to that:
Kernel memory at address 0 is reserved.
crashkernel must be at first RMO, so architecture puts it at 128Mi. However,
kdump-tools currently puts it at @32Mi because of bug
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1567539.
PACA and LPPACA need to be at the first RMO as well, and with 2048 CPUs, they
take more than 5MB and 2MiB, respectively.
With the kernel now taking around 25MB from stext to _end, the kernel
can't reserve enough memory for PACA or LPPACA right after boot, and
it panics.
So, right after installing kdump-tools on artful, and rebooting, the
kernel won't boot, with no sign of life as we haven't even started any
console. Investigation for this issue took an entire day.
The fix would be setting the loading address to 128MiB, and start
reducing size of PACA and maybe remove some of the requirements for
the location of PACA and crash kernel.
I would not even set the loading address of the crash kernel in the
parameter itself, and leave it to the kernel to decide it, which it
already does and already would put it at 128Mi.
Cascardo.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728115/+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
