kernel-packages team mailing list archive

[Brad Figg <brad.figg@xxxxxxxxxxxxx>]

This bug is missing log files that will aid in diagnosing the problem.
>From a terminal window please run:

apport-collect 1515301

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.

** Changed in: linux (Ubuntu)
       Status: New => Incomplete

** Tags added: vivid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1515301

Title:
  [Hyper-V] issues with linux-next on 15.04 kdump functionality

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Using linux-next 4.3.0-next-20151106 kdump is failing to start as a service.
  On RHEL and SLES with upstream, kdump is working as expected so only Ubuntu has this issue as observed from our testing.

  A similar issue with the same error message from kdump has been already reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1400319
  However that behavior was on 32bit Ubuntu only, and now with upstream this seems to extend to 64bit as well.
  So I'm not sure if we should link these 2 bug reports at this point.

  Issues description:
  1. kdump-tools service fails to start on 15.04 64bit, when runnig the linux-next kernel
  Error returned is: Starting kdump-tools: Could not find a free area of memory of 0xa637000 bytes...
  (full log below)
  By default, kdump sets crashkernel to 394M-:128M

  2. If crashkernel is set to 384M, the dump file will fail to create due to OOM messages when a crash is triggered. 
  Attaching the full serial log with crashkernel=384M. The log is the same with 512M as crashkernel.
  Can this be a memory leak in the kdump kernel, making even already high values as 512M for the crashkernel to not be enough?
  VM RAM has been set to 2GB and also 4GB, and with minimal load on the system that isn't a problem.

  Work-around for issue #1:
  Set crashkernel size to 384M, instead of the default 384M-:128M.
  With this, kdump-tools will start.
  However the dump file doesn't get written and the system will hang, without rebooting.

  Values used to trigger a kdump:
  - 384M
  - 512M
  - 384M-:128M - kdump-tools will not properly load.

  Full kdump service log:
  root@ubuntu1504srv:~# service kdump-tools status
  â kdump-tools.service - Kernel crash dump capture service
     Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor preset: enabled)
     Active: active (exited) since Wed 2015-11-11 06:02:28 PST; 20min ago
    Process: 792 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS)
   Main PID: 792 (code=exited, status=0/SUCCESS)
     CGroup: /system.slice/kdump-tools.service

  Nov 11 06:02:20 ubuntu1504srv systemd[1]: Starting Kernel crash dump capture service...
  Nov 11 06:02:28 ubuntu1504srv kdump-tools[792]: Starting kdump-tools: Could not find a free area of memory of 0xa637000 bytes...
  Nov 11 06:02:28 ubuntu1504srv kdump-tools[792]: locate_hole failed
  Nov 11 06:02:28 ubuntu1504srv kdump-tools[792]: * failed to load kdump kernel
  Nov 11 06:02:28 ubuntu1504srv systemd[1]: Started Kernel crash dump capture service.

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