Hari Bathini <hbath...@linux.ibm.com> writes:
> diff --git a/arch/powerpc/kernel/fadump-common.h
> b/arch/powerpc/kernel/fadump-common.h
> index d2dd117..7107cf2 100644
> --- a/arch/powerpc/kernel/fadump-common.h
> +++ b/arch/powerpc/kernel/fadump-common.h
> @@ -66,6 +66,14 @@ static inline u64 fadump_str_to_u64(const char *str)
>
> #define FADUMP_CRASH_INFO_MAGIC fadump_str_to_u64("FADMPINF")
>
> +/*
> + * Amount of memory (1024MB) to skip before making another attempt at
> + * reserving memory (after the previous attempt to reserve memory for
> + * FADump failed due to memory holes and/or reserved ranges) to reduce
> + * the likelihood of memory reservation failure.
> + */
> +#define FADUMP_OFFSET_SIZE 0x40000000U
This seems like a bit of a hack.
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index 971c50d..8dd2dcc 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -371,7 +371,7 @@ int __init fadump_reserve_mem(void)
> !memblock_is_region_reserved(base, size))
> break;
>
> - base += size;
> + base += FADUMP_OFFSET_SIZE;
> }
The comment above the loop says:
/*
* Reserve memory at an offset closer to bottom of the RAM to
* minimize the impact of memory hot-remove operation. We can't
* use memblock_find_in_range() here since it doesn't allocate
* from bottom to top.
*/
Is that true? Can't we set memblock to bottom up mode and then call it?
cheers
