On 10/30/2012 08:39 PM, Zhang, Jun wrote:
Hello, Anvin
Thanks!
Hello, all
Next is my the latest version, please review it.
Thanks!
You're still starting in the wrong end which is confusing for the reader.
What you probably want to say is something more like:
"We are doing a crash dump, so remove all RAM ranges as they are the
ones that need to be dumped. We still need all non-RAM information in
order to do I/O."
At that point it should be pretty obvious that the patch is wrong. What
if we are *not* doing a crash dump? Just because crash dump is compiled
in doesn't mean that that is what we are doing right now.
-hpa
From 141546c77ff7be523a9e72f5259df4a6827f2c1a Mon Sep 17 00:00:00 2001
From: jzha144 <jun.zh...@intel.com>
Date: Wed, 31 Oct 2012 08:51:18 +0800
Subject: [PATCH] If we are doing a crash dump, we still need non-E820_RAM
memory type address information, which come from BIOS or
firmware. for example: PCI_MMCONFIG check this address.
Signed-off-by: jzha144 <jun.zh...@intel.com>
---
arch/x86/kernel/e820.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index df06ade..f8672d0 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p)
* reset.
*/
saved_max_pfn = e820_end_of_ram_pfn();
+
+ /*
+ * If we are doing a crash dump, we still need non-E820_RAM
+ * memory type address information. so we only remove
+ * E820_RAM type.
+ */
+ e820_remove_range(0, ULLONG_MAX, E820_RAM, 1);
+ userdef = 1;
+ return 0;
#endif
e820.nr_map = 0;
userdef = 1;
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/