summaryrefslogtreecommitdiff
path: root/kexec/arch/ppc/crashdump-powerpc.c
diff options
context:
space:
mode:
authorHari Bathini <hbathini@linux.vnet.ibm.com>2017-07-26 22:49:41 +0530
committerSimon Horman <horms@verge.net.au>2017-08-04 13:10:10 +0200
commit47478ea66d4301b12a07862aebc8447a2932f0ed (patch)
tree5f6d57156982c2d60223dc38be921a8aec88baa6 /kexec/arch/ppc/crashdump-powerpc.c
parent161dd0f4f8a830bfed3a3129f08e295d8a274305 (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