Hello, Regarding nr_cpus=1, the equivalent maxcpus=1 is set in the kexec command (at least on default installs) :
$ kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0x2b000000
/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.4.0-17-generic
kdump initrd:
/var/lib/kdump/initrd.img: symbolic link to
/var/lib/kdump/initrd.img-4.4.0-17-generic
current state: ready to kdump
kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/vmlinuz-4.4.0-17-generic
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 irqpoll maxcpus=1
nousb systemd.unit=kdump-tools.service" --initrd=/var/lib/kdump/initrd.img
/var/lib/kdump/vmlinuz
^^^^^^^^^^^
Maybe disabling SMP alltogether by setting maxcpus=0 could be considered
but that shouldn't change much aside from not reserving any SMP data
structure. To Be Tested.
Regarding kvm_cma_resv_ratio=0, this will avoid the error message but
it has on bearing on the current situation. It failed to allocated it so
the memory was not in use.
256Gb of RAM doesn't mean that 128Mb needs to be increased. Here is the
output of free on a 128Gb system right after a kernel panic :
(initramfs) chroot /root free -h
total used free shared buff/cache available
Mem: 99M 20M 21M 48K 57M 62M
Swap: 0B 0B 0B
And here is the memory allocation in the same context :
(initramfs) chroot /root cat /proc/meminfo
MemTotal: 102000 kB
MemFree: 22260 kB
MemAvailable: 63700 kB
Buffers: 1640 kB
Cached: 33944 kB
SwapCached: 0 kB
Active: 12400 kB
Inactive: 23584 kB
Active(anon): 416 kB
Inactive(anon): 28 kB
Active(file): 11984 kB
Inactive(file): 23556 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 408 kB
Mapped: 3128 kB
Shmem: 48 kB
Slab: 23228 kB
SReclaimable: 10568 kB
SUnreclaim: 12660 kB
KernelStack: 1952 kB
PageTables: 96 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 51000 kB
Committed_AS: 1212 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 281500 kB
VmallocChunk: 34358935548 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 27048 kB
DirectMap2M: 104448 kB
DirectMap1G: 0 kB
The 128Mb is used to allocate kernel data structure, load the initrd in
RAM. Then more memory is needed for makedumpfile to read, convert and
compress /proc/vmcore into a file. Since makedumpfile 1.5.5 it uses a
memory footprint that is rather stable and minimally increase depending
on the size of the RAM.
In this case, makedumpfile has not even started to execute so it is also
safe to exclude that as the source of the problem.
This in return indicates a problem :
[ 0.000000] bootmem alloc of 41943040 bytes failed!
[ 0.000000] Kernel panic - not syncing: Out of memory
This is very early on boot and it fails to allocate 40Mb of memory for
bootmem. My suspicion is that it is unable to allocate that memory at
the start of the memory.
The only information I could gather by a quick google search is this :
https://www.novell.com/support/kb/doc.php?id=3374462
For SLES, they suggest to allocate the memory starting at 32M so you
might want to replace the crashkernel value by :
crashkernel=128M@32M and see if it helps.
I will continue the analysis in the meantime but I don't thing that
raising the value higher will help as 40Mb is well within the 128Mb
limit.
And a good blogpost on the usage of crashkernel is now a definite
requirement.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1567539
Title:
Failure to dump with trusty+3.16 on ppc64el
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1567539/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
