Jordan Crouse wrote: > On 27/09/07 15:47 -0700, H. Peter Anvin wrote: >> Jordan Crouse wrote: >>> Breaks on the Geode - original behavior. >>> >>> I think that having boot_prams.e820_entries != 0 makes the kernel >>> assume the e820 data is correct. >>> >> Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode, >> because this, to the best of my reading, mimics the 2.6.22 behavior >> exactly. DID IT REALLY, and/or did you make any kind of configuration >> changes? > > I copied in a 2.6.22 kernel to see that it really did work, and it did. > But here's the crazy part - I did a dmesg, and it looks like it > *is* using e820 data, and it looks complete (I see the entire map - > including the ACPI and reserved blocks way up high). > > So apparently it was the 2.6.22 code that was buggy, but reading it, > I don't immediately see how. >
Oh bugger, looks like this one might be genuinely my fault after all. The ID check in the new code is buggy. Can you please test this revised patch out (against current -git)? -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++;