Ubuntu
linux package

ISST-LTE: high cpus number need a high crashkernel value in kdump

Bug #1546159 reported by bugproxy
6
This bug affects 1 person
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://lists.ozlabs.org/pipermail/linuxppc-dev/2016-February/138619.html
---

Heads up Canonical: We'll want this patch included as soon possible/practical.

Revision history for this message
bugproxy (bugproxy) wrote : kdump success with 40 cpus

Default Comment by Bridge

tags: added: architecture-ppc64le bugnameltc-134503 severity-high targetmilestone-inin---
Revision history for this message
bugproxy (bugproxy) wrote : kdump fail with 200 cpus

Default Comment by Bridge

Changed in ubuntu:
assignee: nobody → Taco Screen team (taco-screen-team)
Kevin W. Rudd (kevinr)
affects: ubuntu → linux (Ubuntu)
Leann Ogasawara (leannogasawara)
Changed in linux (Ubuntu):
assignee: Taco Screen team (taco-screen-team) → Canonical Kernel Team (canonical-kernel-team)
importance: Undecided → High
status: New → Triaged
Revision history for this message
Tim Gardner (timg-tpi) wrote :

Lemme know when this patch makes it into linux-next.

Changed in linux (Ubuntu Xenial):
assignee: Canonical Kernel Team (canonical-kernel-team) → Tim Gardner (timg-tpi)
status: Triaged → In Progress
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-03-07 13:06 EDT-------
Was this patch sent to linux-next?

Revision history for this message
Tim Gardner (timg-tpi) wrote :

I cannot find any forward progress on this patch.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-04-18 16:22 EDT-------
It looks like the LP side of this bug was tagged to Xenial when this bug was supposed to be against Trusty. We need the same change that was applied to Xenial via LP Bug #1560552 applied to the Trusty release.

Revision history for this message
Tim Gardner (timg-tpi) wrote :

That patch (http://patchwork.ozlabs.org/patch/577193/) should have made it upstream by now. What is going on with it ?

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-04-28 09:20 EDT-------
(In reply to comment #20)
> That patch (http://patchwork.ozlabs.org/patch/577193/) should have made it
> upstream by now. What is going on with it ?

Mahesh spoke to PPC Maintainer offline about this patch. Since the changes are more invasive (and at the code path which is used at every boot) review is taking time. Maintainer is also thinking about alternate solution but that includes rewriting lots of cpu numbering code. So as of now maintainer conveyed that he needs some more time (hasn't mention specific time) to review this patch to be very sure that it is not harmful.

So as it stands, this patch may not be going anywhere at least for some time..

Thanks
Hari

Tim Gardner (timg-tpi)
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
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.