Hi Michal,
Thanks for the review..
On Monday 22 May 2017 04:25 PM, Michal Suchánek wrote:
On Mon, 22 May 2017 15:04:47 +0530
Hari Bathini <hbath...@linux.vnet.ibm.com> wrote:
With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset
closer to bottom of RAM"), memory for fadump is no longer reserved at
the top of RAM. But there are still a few places which say so. Change
them appropriately.
Signed-off-by: Hari Bathini <hbath...@linux.vnet.ibm.com>
---
Documentation/powerpc/firmware-assisted-dump.txt | 4 ++--
arch/powerpc/kernel/fadump.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/firmware-assisted-dump.txt
b/Documentation/powerpc/firmware-assisted-dump.txt index
9cabaf8..bdd344a 100644 ---
a/Documentation/powerpc/firmware-assisted-dump.txt +++
b/Documentation/powerpc/firmware-assisted-dump.txt @@ -61,8 +61,8 @@
as follows: boot successfully. For syntax of crashkernel= parameter,
refer to Documentation/kdump/kdump.txt. If any offset is
provided in crashkernel= parameter, it will be ignored
- as fadump reserves memory at end of RAM for boot memory
- dump preservation in case of a crash.
+ as fadump uses a predefined offset to reserve memory
+ for boot memory dump preservation in case of a crash.
What is the reason for fadump to prefer a random offset calculated by
the kernel over a random offset supplied by the user?
An offset provided by user needs multiple checks failing which can be
tricky.
While implementation is still possible, it makes the code complicated for no
practical gain as commit f6e6bedb7731 is already calculating the best
possible
offset..
Thanks
Hari
