ISST-LTE: high cpus number need a high crashkernel value in kdump
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Triaged
|
High
|
Unassigned | ||
Xenial |
Triaged
|
High
|
Unassigned |
Bug Description
---Problem Description---
The kdump kernel will be booted with "maxcpus=1", so no matter how many cpus this system has, only one cpu will be brought up during kdump I think. But on LPAR thymelp2, if we allocate 40 cpus on it, then kdump works just fine with 512M as crashkernel value. But if we allocate 200 cpus on it, kdump fails by trggering OOM. It has been proved that in latter situation we need 1.5G RAM reserved for kdump to let it works.
---Steps to Reproduce---
1. configure kdump with crashkernel=512M on thymelp2
2. allcoate 40 cpus on thymelp2 and trigger kdump
3. allocate 200 cpus on thymelp2 then do kdump again
---
Mahesh has posted a patch upstream to provide support for nr_cpus in kdump kernel.
That should take care of this problem..
https:/
---
Heads up Canonical: We'll want this patch included as soon possible/practical.
affects: | ubuntu → linux (Ubuntu) |
Changed in linux (Ubuntu): | |
assignee: | Taco Screen team (taco-screen-team) → Canonical Kernel Team (canonical-kernel-team) |
importance: | Undecided → High |
status: | New → Triaged |
Changed in linux (Ubuntu): | |
assignee: | Tim Gardner (timg-tpi) → nobody |
Changed in linux (Ubuntu Xenial): | |
assignee: | Tim Gardner (timg-tpi) → nobody |
Changed in linux (Ubuntu): | |
status: | In Progress → Triaged |
Changed in linux (Ubuntu Xenial): | |
status: | In Progress → Triaged |
Default Comment by Bridge