On Wed, Jul 26, 2017 at 10:49:41PM +0530, Hari Bathini wrote:
> 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 at linux.vnet.ibm.com>
> Cc: Michael Ellerman <mpe at ellerman.id.au>
> Cc: Geoff Levand <geoff at infradead.org>
> Signed-off-by: Hari Bathini <hbathini at linux.vnet.ibm.com>
Thanks, applied.
