[Bug 785394] Re: Hard-coded crashkernel=... memory reservation in /etc/grub.d/10_linux is insufficient

[Louis Bouchard]

@apw

After our meeting at UDS-P, you suggested to change the following in
/etc/initramfs/initramfs.conf :

#
# MODULES: [ most | netboot | dep | list ]
#
# most - Add most filesystem and all harddrive drivers.
#
# dep - Try and guess which modules to load.
#
# netboot - Add the base modules, network modules, but skip block devices.
#
# list - Only include modules from the 'additional modules' list
#

MODULES=dep

from MODULES=most and to rebuild the initramfs

I have tested this and I still see the OOM killer kicking in while the
kexec booted kernel is trying to start.

One thing that I noticed is that the memory information displayed while the OOM killer is active is the following :
[    2.810045] active_anon:5339 inactive_anon:33 isolated_anon:0
[    2.810046]  active_file:0 inactive_file:0 isolated_file:0
[    2.810046]  unevictable:1635 dirty:0 writeback:0 unstable:0
[    2.810047]  free:280 slab_reclaimable:1007 slab_unreclaimable:1363
[    2.810048]  mapped:428 shmem:40 pagetables:727 bounce:0
[    2.813342] Node 0 DMA free:208kB min:4kB low:4kB high:4kB active_anon:328kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictabl
e:0kB isolated(anon):0kB isolated(file):0kB present:320kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_u
nreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[    2.817647] lowmem_reserve[]: 0 51 51 51
[    2.818158] Node 0 DMA32 free:912kB min:912kB low:1140kB high:1368kB active_anon:21028kB inactive_anon:132kB active_file:0kB inactive_file:
0kB unevictable:6540kB isolated(anon):0kB isolated(file):0kB present:52780kB mlocked:0kB dirty:0kB writeback:0kB mapped:1712kB shmem:160kB sla
b_reclaimable:4028kB slab_unreclaimable:5444kB kernel_stack:776kB pagetables:2908kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 
all_unreclaimable? yes
[    2.823024] lowmem_reserve[]: 0 0 0 0
[    2.823937] Node 0 DMA: 0*4kB 0*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 208kB
[    2.826354] Node 0 DMA32: 3*4kB 0*8kB 0*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 908kB
[    2.828162] 1675 total pagecache pages
[    2.828597] 0 pages in swap cache
[    2.828978] Swap cache stats: add 0, delete 0, find 0/0
[    2.829585] Free swap  = 0kB
[    2.829919] Total swap = 0kB
[    2.831199] 61419 pages RAM
[    2.831580] 49505 pages reserved
[    2.831957] 7209 pages shared
[    2.832340] 11055 pages non-shared

There are 49505 reserved pages, compared with only 22984 pages on the
running kernel when the VM is booted.

Of course, this issue goes away if the system/VM memory goes above 2G
but this is still an issue with smaller amount of memory.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/785394

Title:
  Hard-coded crashkernel=... memory reservation in /etc/grub.d/10_linux
  is insufficient

Status in “grub2” package in Ubuntu:
  Confirmed
Status in “kexec-tools” package in Ubuntu:
  In Progress

Bug description:
  Binary package hint: grub-pc

  This concerns grub-pc 1.99~rc1-13ubuntu3 in Ubuntu Natty.

  The /etc/grub.d/10_linux file contains this snippet:

      # add crashkernel option if we have the required tools
      if [ -x "/usr/bin/makedumpfile" ] && [ -x "/sbin/kexec" ]; then
          GRUB_CMDLINE_EXTRA="$GRUB_CMDLINE_EXTRA crashkernel=384M-2G:64M,2G-:128M"
      fi

  I am on a system with 2GB of RAM (reported as 2038MB), and according
  to the kernel startup messages, 64MB is reserved for the crash kernel.

  Unfortunately, this does not appear to be enough memory for the
  regular Ubuntu kernel to boot. I am attaching a kernel log obtained
  via serial cable; it shows the initial boot, a crash in the kernel's
  video-driver-related code, the subsequent crashkernel boot, and then
  an apparent "out of memory" kernel panic. (A side effect of the
  "double crash" is that the system is left unresponsive, requiring a
  manual reset instead of rebooting itself automatically.)

  If I double the memory numbers in the crashkernel=... argument, so
  that the reservation is 128MB, the system correctly goes on to attempt
  a vmcore dump and reboot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/785394/+subscriptions