From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "d.hatayama@jp.fujitsu.com" <d.hatayama@jp.fujitsu.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: makedumpfile: get_max_mapnr() from ELF header problem
Date: Thu, 20 Mar 2014 11:23:59 +0100 [thread overview]
Message-ID: <20140320112359.25f0ad54@holzheu> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE971F7B95@BPXM01GP.gisp.nec.co.jp>
On Wed, 19 Mar 2014 07:14:25 +0000
Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:
> >Hello Atsushi,
> >
> >I debugged my problem a bit further and tried to implement
> >a function that gets the maximum page frame number from the
> >Linux kernel memory management structures.
> >
> >I am no memory management expert, so the following patch probably
> >is not complete, but at least for my setup it worked.
>
> The patch looks good for your case, but I don't think it's a proper
> approach for this problem.
Hello Atsushi,
If you don't like that solution, what about using the mem_map_data[]
array of makedumpfile to adjust "max_mapnr"?
The patch below also works fine for my dump.
Michael
---
makedumpfile.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2829,7 +2829,8 @@ get_mem_map_without_mm(void)
int
get_mem_map(void)
{
- int ret;
+ unsigned long max_pfn = 0;
+ int ret, i;
switch (get_mem_type()) {
case SPARSEMEM:
@@ -2861,6 +2862,17 @@ get_mem_map(void)
ret = FALSE;
break;
}
+ /*
+ * Adjust "max_mapnr" for the case that Linux uses less memory
+ * than is dumped. For example when "mem=" has been used for the
+ * dumped system.
+ */
+ for (i = 0; i < info->num_mem_map; i++) {
+ if (info->mem_map_data[i].mem_map == NOT_MEMMAP_ADDR)
+ continue;
+ max_pfn = MAX(max_pfn, info->mem_map_data[i].pfn_end);
+ }
+ info->max_mapnr = max_pfn;
return ret;
}
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-03-20 10:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 12:41 makedumpfile: get_max_mapnr() from ELF header problem Michael Holzheu
2014-03-03 3:11 ` Atsushi Kumagai
2014-03-03 9:44 ` Michael Holzheu
2014-03-11 6:22 ` Atsushi Kumagai
2014-03-11 11:35 ` Michael Holzheu
2014-03-12 4:15 ` HATAYAMA Daisuke
2014-03-12 6:01 ` Atsushi Kumagai
2014-03-12 16:18 ` Michael Holzheu
2014-03-14 8:54 ` Atsushi Kumagai
2014-03-14 14:19 ` Michael Holzheu
2014-03-19 7:14 ` Atsushi Kumagai
2014-03-19 18:29 ` Michael Holzheu
2014-03-20 10:23 ` Michael Holzheu [this message]
[not found] ` <20140319180903.2c6e2b72@holzheu>
2014-03-25 1:14 ` Atsushi Kumagai
2014-03-25 15:24 ` Michael Holzheu
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=20140320112359.25f0ad54@holzheu \
--to=holzheu@linux.vnet.ibm.com \
--cc=d.hatayama@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
/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