From: Vivek Goyal <vgoyal@in.ibm.com>
To: linux kernel mailing list <linux-kernel@vger.kernel.org>,
Fastboot mailing list <fastboot@lists.osdl.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
Morton Andrew Morton <akpm@osdl.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
galak@kernel.crashing.org, gregkh@suse.de, bcrl@kvack.org,
Dave Jiang <dave.jiang@gmail.com>,
arjan@infradead.org, Maneesh Soni <maneesh@in.ibm.com>,
Murali <muralim@in.ibm.com>
Subject: [RFC][PATCH 10/10] i386: export memory more than 4G through /proc/iomem
Date: Thu, 23 Mar 2006 15:11:34 -0500 [thread overview]
Message-ID: <20060323201134.GN7175@in.ibm.com> (raw)
In-Reply-To: <20060323201018.GM7175@in.ibm.com>
o Currently /proc/iomem exports physical memory also apart from io device
memory. But on i386, it truncates any memory more than 4GB. This leads
to problems for kexec/kdump.
o Kexec reads /proc/iomem to determine the system memory layout and prepares
a memory map based on that and passes it to the kernel being kexeced. Given
the fact that memory more than 4GB has been truncated, new kernel never
gets to see and use that memory.
o Kdump also reads /proc/iomem to determine the physical memory layout of
the system and encodes this informaiton in ELF headers. After a crash
new kernel parses these ELF headers being used by previous kernel and
vmcore is prepared accordingly. As memory more than 4GB has been truncated,
kdump never sees that memory and never prepares ELF headers for it. Hence
vmcore is truncated and limited to 4GB even if there is more physical
memory in the system.
o This patch exports memory more than 4GB through /proc/iomem on i386.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---
arch/i386/kernel/setup.c | 2 --
1 files changed, 2 deletions(-)
diff -puN arch/i386/kernel/setup.c~i386-export-mem-more-than-4G-through-proc-iomem arch/i386/kernel/setup.c
--- linux-2.6.16-mm1/arch/i386/kernel/setup.c~i386-export-mem-more-than-4G-through-proc-iomem 2006-03-23 11:39:24.000000000 -0500
+++ linux-2.6.16-mm1-root/arch/i386/kernel/setup.c 2006-03-23 11:39:24.000000000 -0500
@@ -1295,8 +1295,6 @@ legacy_init_iomem_resources(struct resou
probe_roms();
for (i = 0; i < e820.nr_map; i++) {
struct resource *res;
- if (e820.map[i].addr + e820.map[i].size > 0x100000000ULL)
- continue;
res = kzalloc(sizeof(struct resource), GFP_ATOMIC);
switch (e820.map[i].type) {
case E820_RAM: res->name = "System RAM"; break;
_
next prev parent reply other threads:[~2006-03-23 20:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-23 19:57 [RFC][PATCH 0/10] 64 bit resources Vivek Goyal
2006-03-23 19:59 ` [RFC][PATCH 1/10] 64 bit resources core changes Vivek Goyal
2006-03-23 20:01 ` [RFC][PATCH 2/10] 64 bit resources drivers pci changes Vivek Goyal
2006-03-23 20:02 ` [RFC][PATCH 3/10] 64 bit resources drivers ide changes Vivek Goyal
2006-03-23 20:03 ` [RFC][PATCH 4/10] 64 bit resources drivers media changes Vivek Goyal
2006-03-23 20:04 ` [RFC][PATCH 5/10] 64 bit resources drivers net changes Vivek Goyal
2006-03-23 20:06 ` [RFC][PATCH 6/10] 64 bit resources drivers pcmcia changes Vivek Goyal
2006-03-23 20:07 ` [RFC][PATCH 7/10] 64 bit resources drivers others changes Vivek Goyal
2006-03-23 20:09 ` [RFC][PATCH 8/10] 64 bit resources sound changes Vivek Goyal
2006-03-23 20:10 ` [RFC][PATCH 9/10] 64 bit resources arch changes Vivek Goyal
2006-03-23 20:11 ` Vivek Goyal [this message]
2006-03-24 12:15 ` [RFC][PATCH 3/10] 64 bit resources drivers ide changes Alan Cox
2006-03-24 14:43 ` Vivek Goyal
2006-03-23 20:22 ` [RFC][PATCH 1/10] 64 bit resources core changes Arjan van de Ven
2006-03-23 20:41 ` Vivek Goyal
2006-03-23 20:52 ` Linus Torvalds
2006-03-23 20:56 ` Arjan van de Ven
2006-03-23 21:02 ` Al Viro
2006-03-23 21:07 ` Arjan van de Ven
2006-03-23 21:21 ` Al Viro
2006-03-23 21:01 ` Al Viro
2006-04-14 21:07 ` Matthieu CASTET
2006-03-24 9:12 ` [RFC][PATCH 0/10] 64 bit resources Andrew Morton
2006-03-24 18:05 ` Vivek Goyal
2006-03-28 16:34 ` Kumar Gala
2006-03-28 22:24 ` Vivek Goyal
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=20060323201134.GN7175@in.ibm.com \
--to=vgoyal@in.ibm.com \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=bcrl@kvack.org \
--cc=dave.jiang@gmail.com \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=galak@kernel.crashing.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@in.ibm.com \
--cc=muralim@in.ibm.com \
--cc=torvalds@osdl.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.