As luck would have it, it's not just an obscure Geode system which has a
broken E820 implementation. Today I received a bug report about a Dell
system (XPS M1330) with broken E820.
Unfortunately, the workaround for the Geode breaks this system, because
x86-64 doesn't fall back to the e801/88 information like the i386 kernel
does.
I wonder if the relevant people could test out this patch to see how it
works on their respective system. This patch reverts to 2.6.23-rc8
behaviour of simply truncating the map, but still makes e801/88 info
available to the kernel; this hopefully should match 2.6.22 behaviour.
I want to emphasize that this is seriously broken. Using a partial e820
map could have disastrous results, since the kernel will have partial
memory map information and not know about reserved areas, etc. Part of
me feels that the right thing to do is what the current git kernel does
-- either fall back to e801, or stop and error.
(Andi: I would particularly appreciate your opinion on this issue.)
-hpa
diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index bccaa1c..84939b7 100644
--- a/arch/i386/boot/memory.c
+++ b/arch/i386/boot/memory.c
@@ -34,17 +34,7 @@ static int detect_memory_e820(void)
"=m" (*desc)
: "D" (desc), "a" (0xe820));
- /* Some BIOSes stop returning SMAP in the middle of
- the search loop. We don't know exactly how the BIOS
- screwed up the map at that point, we might have a
- partial map, the full map, or complete garbage, so
- just return failure. */
- if (id != SMAP) {
- count = 0;
- break;
- }
-
- if (err)
+ if (id != SMAP || err)
break;
count++;
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
