From: Hari Bathini <hbathini@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Prarit Bhargava <prarit@redhat.com>,
linuxppc-dev <linuxppc-dev@ozlabs.org>,
Ankit Kumar <ankit@linux.vnet.ibm.com>,
Dave Young <dyoung@redhat.com>,
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
Subject: [PATCH 2/2] powerpc/fadump: update about offset where fadump is reserved
Date: Mon, 22 May 2017 15:04:47 +0530 [thread overview]
Message-ID: <149544568763.16888.16656118217496342159.stgit@hbathini.in.ibm.com> (raw)
In-Reply-To: <149544566391.16888.187413825827689513.stgit@hbathini.in.ibm.com>
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 <hbathini@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.
-- After the low memory (boot memory) area has been saved, the
firmware will reset PCI and other hardware state. It will
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index c0db844..63c4281 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -218,8 +218,8 @@ static inline unsigned long fadump_calculate_reserve_size(void)
/*
* Check if the size is specified through crashkernel= cmdline
- * option. If yes, then use that but ignore base as fadump
- * reserves memory at end of RAM.
+ * option. If yes, then use that but ignore base as fadump reserves
+ * memory at a predefined offset.
*/
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
&size, &base);
next prev parent reply other threads:[~2017-05-22 9:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 9:34 [PATCH 1/2] powerpc/fadump: add a warning when 'fadump_reserve_mem=' is used Hari Bathini
2017-05-22 9:34 ` Hari Bathini [this message]
2017-05-22 10:55 ` [PATCH 2/2] powerpc/fadump: update about offset where fadump is reserved Michal Suchánek
2017-05-22 18:56 ` Hari Bathini
2017-06-05 10:21 ` [1/2] powerpc/fadump: add a warning when 'fadump_reserve_mem=' is used Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=149544568763.16888.16656118217496342159.stgit@hbathini.in.ibm.com \
--to=hbathini@linux.vnet.ibm.com \
--cc=ankit@linux.vnet.ibm.com \
--cc=dyoung@redhat.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mahesh@linux.vnet.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=prarit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).