← Back to team overview

kernel-packages team mailing list archive

[Bug 1570775] Comment bridged from LTC Bugzilla


------- Comment From thorsten.diehl@xxxxxxxxxx 2016-05-03 07:28 EDT-------
On an LPAR with 8458 (!!) ccw devices (only 11 of them in use) I set crashkernel with various values:
256M : no dump created
288M : oom killer killed some processes, dump was created, but system did not come up
320M : no oom killer, dump properly created
Then I invoked cio_ignore -u -k and added these values to KDUMP_CMD_APPEND in /etc/default/kdump_tools. Kdump worked fine, even with crashkernel=128M

IMO the best thing is to set this dynamically in /etc/default/kdump_tools by the following suggested patch:
--- /etc/default/kdump-tools.orig	2016-04-21 15:11:57.000000000 +0200
+++ /etc/default/kdump-tools	2016-05-03 13:17:38.862816261 +0200
@@ -63,7 +63,8 @@
#     for the kdump kernel.  If unset, it defaults to "irqpoll maxcpus=1 nousb"
-#KDUMP_CMDLINE_APPEND="irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service"
+KDUMP_CMDLINE_APPEND="irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service $APPEND"

# ---------------------------------------------------------------------------
# Architecture specific Overrides:

The cmdline during kdump is set properly, the values from cio_ignore are

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.

  makekdump should re-exec with cio_ignore on s390x

Status in Ubuntu on IBM z Systems:
Status in makedumpfile package in Ubuntu:

Bug description:
  As per

  We should re-exec with cio_ignore lines. As per report there, it
  should result in lowered required crashdump setting.

  Hypothetically, one should be able to test this imperially by lowering
  crashdump memory settings until kdump does not succeed anymore. And
  then generated and append `cio_ignore -k -u` to the
  KDUMP_CMDLINE_APPEND= and see that kdump starts working again with a
  lower memory usage.

  Once this is developed / verified / tested, we should probably SRU
  this back to xenial.

To manage notifications about this bug go to: