nathan.zook@amd.com wrote:
> The data LOOKS reasonable. I see two likely issues. The first is that the
> 64-bit data is being truncated in printout to 32 bits. It is concievable
> that there are high bits begin reported, causing a region to be unavailable.
> The report is on line 434 of arch/i386/kernel/setup.c
Please apply:
diff -u /usr/src/linux/arch/i386/kernel/setup.c.e820 /usr/src/linux/arch/i386/kernel/setup.c
--- /usr/src/linux/arch/i386/kernel/setup.c.e820 Sun Jan 2 02:34:32 2000
+++ /usr/src/linux/arch/i386/kernel/setup.c Fri Jan 7 12:56:27 2000
@@ -431,8 +431,8 @@
memcpy(e820.map, E820_MAP, e820.nr_map * sizeof e820.map[0]);
#ifdef E820_DEBUG
for (i=0; i < e820.nr_map; i++) {
- printk("e820: %08x @ %08x ", (int)e820.map[i].size,
- (int)e820.map[i].addr);
+ printk("e820: %016Lx @ %016Lx ",
+ e820.map[i].size, e820.map[i].addr);
switch (e820.map[i].type) {
case E820_RAM: printk("(usable)\n");
break;
> What seems far more likely is that the 0xE8000-0xEBFFF region is the
> problem. AFAIK, Linux believes basically in three memory classes: 0-640k,
> 1M-1G, 1G-64G. 0xE8000 does not exactly fit into these regions, and the
> ACPI spec states that the 0xE0000-0xEFFFF region is boards specific in its
> characteristics. If you are brave, you might h-h-h-h-ack thing by adding
> this test to the loop in line 648-678 to skip this region:
> if(i == 2) { i++; };
Yes, that works!
fwiw, this comment in mm/init.c is in the wrong place. The
`page_is_ram' function is only used for high memory. The comment should
be in kernel/setup.c if anywhere.
diff -u /usr/src/linux/arch/i386/mm/init.c.e820 /usr/src/linux/arch/i386/mm/init.c
--- /usr/src/linux/arch/i386/mm/init.c.e820 Sun Jan 2 02:33:44 2000
+++ /usr/src/linux/arch/i386/mm/init.c Fri Jan 7 13:24:12 2000
@@ -528,11 +528,6 @@
if (e820.map[i].type != E820_RAM) /* not usable memory */
continue;
- /*
- * !!!FIXME!!! Some BIOSen report areas as RAM that
- * are not. Notably the 640->1Mb area. We need a sanity
- * check here.
- */
addr = (e820.map[i].addr+PAGE_SIZE-1) >> PAGE_SHIFT;
end = (e820.map[i].addr+e820.map[i].size) >> PAGE_SHIFT;
if ((pagenr >= addr) && (pagenr < end))
> This would go in line 650. If you are brave, you might try this & see if
> things work. The proper patch to check this is a bit more involved, and I'm
> going home right now. I'll check back this evening.
I'd be inclined to put all the e820 corrections in one place, perhaps by
altering the map in setup_memory_region. How about defining a new type
E820_UNUSABLE and changing broken usable regions to unusable ones, so
they show up in the log.
My Toshiba is now working with Pavel's memory test, when I disable the
region 4000@e8000 by h-h-h-hack.
e820: 000000000009fc00 @ 0000000000000000 (usable)
e820: 0000000000000400 @ 000000000009fc00 (reserved)
e820: 0000000000004000 @ 00000000000e8000 (usable)
e820: 0000000000010000 @ 00000000000f0000 (reserved)
e820: 0000000003ee0000 @ 0000000000100000 (usable)
e820: 0000000000010000 @ 0000000003fe0000 (ACPI data)
e820: 0000000000010000 @ 0000000003ff0000 (reserved)
e820: 0000000000016e00 @ 00000000100a0000 (reserved)
e820: 0000000000000200 @ 00000000100b6e00 (ACPI NVS)
e820: 0000000000049000 @ 00000000100b7000 (reserved)
e820: 0000000000080000 @ 00000000fff80000 (reserved)
On node 0 totalpages: 00003fe0
enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:09 EST