diff options
author | Hari Bathini <hbathini@linux.vnet.ibm.com> | 2017-07-26 22:49:41 +0530 |
---|---|---|
committer | Simon Horman <horms@verge.net.au> | 2017-08-04 13:10:10 +0200 |
commit | 47478ea66d4301b12a07862aebc8447a2932f0ed (patch) | |
tree | 5f6d57156982c2d60223dc38be921a8aec88baa6 /kexec/arch/ppc/crashdump-powerpc.c | |
parent | 161dd0f4f8a830bfed3a3129f08e295d8a274305 (diff) |
kexec-tools: ppc64: fix how RMA top is deduced
Hang was observed, in purgatory, on a machine configured with
single LPAR. This was because one of the segments was loaded
outside the actual Real Memory Area (RMA) due to wrongly
deduced RMA top value.
Currently, top of real memory area, which is crucial for loading
kexec/kdump kernel, is obtained by iterating through mem nodes
and setting its value based on the base and size values of the
last mem node in the iteration. That can't always be correct as
the order of iteration may not be same and RMA base & size are
always based on the first memory property. Fix this by setting
RMA top value based on the base and size values of the memory
node that has the smallest base value (first memory property)
among all the memory nodes.
Also, correct the misnomers rmo_base and rmo_top to rma_base
and rma_top respectively.
While how RMA top is deduced was broken for sometime, the issue
may not have been seen so far, for couple of possible reasons:
1. Only one mem node was available.
2. First memory property has been the last node in
iteration when multiple mem nodes were present.
Fixes: 02f4088ffded ("kexec fix ppc64 device-tree mem node")
Reported-by: Ankit Kumar <ankit@linux.vnet.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Geoff Levand <geoff@infradead.org>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Diffstat (limited to 'kexec/arch/ppc/crashdump-powerpc.c')
0 files changed, 0 insertions, 0 deletions