* [PATCH] Fix memmap=exactmap boot argument
@ 2008-09-09 13:56 Prarit Bhargava
2008-09-09 14:37 ` Ingo Molnar
0 siblings, 1 reply; 2+ messages in thread
From: Prarit Bhargava @ 2008-09-09 13:56 UTC (permalink / raw)
To: linux-kernel, dzickus, nhorman, vgoyal; +Cc: Prarit Bhargava
When using kdump modifying the e820 map is yielding strange results.
For example starting with
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000100 - 0000000000093400 (usable)
BIOS-e820: 0000000000093400 - 00000000000a0000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
BIOS-e820: 000000003fee0000 - 000000003fef3000 (ACPI data)
BIOS-e820: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
and booting with args
memmap=exactmap memmap=640K@0K memmap=5228K@16384K memmap=125188K@22252K memmap=76K#1047424K memmap=564K#1047500K
resulted in:
user-defined physical RAM map:
user: 0000000000000000 - 0000000000093400 (usable)
user: 0000000000093400 - 00000000000a0000 (reserved)
user: 0000000000100000 - 000000003fee0000 (usable)
user: 000000003fee0000 - 000000003fef3000 (ACPI data)
user: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
user: 000000003ff80000 - 0000000040000000 (reserved)
user: 00000000e0000000 - 00000000f0000000 (reserved)
user: 00000000fec00000 - 00000000fec10000 (reserved)
user: 00000000fee00000 - 00000000fee01000 (reserved)
user: 00000000ff000000 - 0000000100000000 (reserved)
But should have resulted in:
user-defined physical RAM map:
user: 0000000000000000 - 00000000000a0000 (usable)
user: 0000000001000000 - 000000000151b000 (usable)
user: 00000000015bb000 - 0000000008ffc000 (usable)
user: 000000003fee0000 - 000000003ff80000 (ACPI data)
This is happening because of an improper usage of strcmp() in the
e820 parsing code. The strcmp() always returns !0 and never resets the
value for e820.nr_map and returns an incorrect user-defined map.
This patch fixes the problem.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 9af8907..66e48aa 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1203,7 +1203,7 @@ static int __init parse_memmap_opt(char *p)
if (!p)
return -EINVAL;
- if (!strcmp(p, "exactmap")) {
+ if (!strncmp(p, "exactmap", 8)) {
#ifdef CONFIG_CRASH_DUMP
/*
* If we are doing a crash dump, we still need to know
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Fix memmap=exactmap boot argument
2008-09-09 13:56 [PATCH] Fix memmap=exactmap boot argument Prarit Bhargava
@ 2008-09-09 14:37 ` Ingo Molnar
0 siblings, 0 replies; 2+ messages in thread
From: Ingo Molnar @ 2008-09-09 14:37 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: linux-kernel, dzickus, nhorman, vgoyal
* Prarit Bhargava <prarit@redhat.com> wrote:
> When using kdump modifying the e820 map is yielding strange results.
[...]
>
> This is happening because of an improper usage of strcmp() in the
> e820 parsing code. The strcmp() always returns !0 and never resets the
> value for e820.nr_map and returns an incorrect user-defined map.
>
> This patch fixes the problem.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
applied to tip/x86/urgent, thanks Prarit!
Ingo
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-09-09 14:37 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-09 13:56 [PATCH] Fix memmap=exactmap boot argument Prarit Bhargava
2008-09-09 14:37 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome