This is a HACK. This is ONLY a hack. If this had been a genuine patch, you
would have recieved assurances that it would solve your problems. But it
might anyway.
The first hunk reports the full 64-bit values, so we can be happy that the
data is reasonable. The second blocks out all regions which overlap the dos
high memory region (0x0A0000-0x100000), and is not safe for general use.
Nathan
--- arch/i386/kernel/setup.c.bck Fri Jan 7 01:04:43 2000
+++ arch/i386/kernel/setup.c Fri Jan 7 01:04:43 2000
@@ -431,8 +431,9 @@
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("%lx %08lx %lx %08lx ",
+ (long)((e820.map[i].addr) >> 32),(long)
(e820.map[i].addr),
+ (long)((e820.map[i].size) >> 32), (long)
(e820.map[i].size));
switch (e820.map[i].type) {
case E820_RAM: printk("(usable)\n");
break;
@@ -672,6 +673,10 @@
*/
if (last_pfn <= curr_pfn)
continue;
+
+ if ( e820.map[i].addr < 0x100000 &&
+ e820.map[i].addr + e820.map[i].size > 0x0A0000)
+ continue;
size = last_pfn - curr_pfn;
free_bootmem(PFN_PHYS(curr_pfn), PFN_PHYS(size));
> -----Original Message-----
> From: Zook, Nathan
> Sent: Thursday, January 06, 2000 6:40 PM
> To: lkd@tantalophile.demon.co.uk; orc@pell.portland.or.us
> Cc: pavel@suse.cz; david+nospam@killerlabs.com;
> linux-kernel@vger.rutgers.edu; andre@suse.com
> Subject: RE: Memory detection is still broken in 2.3.36
>
> I've added Parsons to the direct list.
>
> 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
>
> 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++; };
>
> 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.
>
> Nathan
>
>
>
>
>
>
>
> -----Original Message-----
> From: Jamie Lokier [mailto:lkd@tantalophile.demon.co.uk]
> Sent: Thursday, January 06, 2000 11:34 AM
> To: Zook, Nathan
> Cc: pavel@suse.cz; david+nospam@killerlabs.com;
> linux-kernel@vger.rutgers.edu; andre@suse.com
> Subject: Re: Memory detection is still broken in 2.3.36
>
>
> nathan.zook@amd.com wrote:
> > I've dropped Linus off the direct list. I think we should be able to
> debug
> > this one w/o his help. ;-)
> >
> > Lines 594-606 of setup.c, which is the old section cause problems with
> > 0-length regions, now properly handles them. This must be some new
> problem.
> >
> > Could we have the e820 data out of /var/log/dmesg? head should work.
>
> Jan 6 05:03:56 thefinal kernel: e820: 0009fc00 @ 00000000 (usable)
> Jan 6 05:03:56 thefinal kernel: e820: 00000400 @ 0009fc00 (reserved)
> Jan 6 05:03:56 thefinal kernel: e820: 00004000 @ 000e8000 (usable)
> Jan 6 05:03:56 thefinal kernel: e820: 00010000 @ 000f0000 (reserved)
> Jan 6 05:03:56 thefinal kernel: e820: 03ee0000 @ 00100000 (usable)
> Jan 6 05:03:56 thefinal kernel: e820: 00010000 @ 03fe0000 (ACPI data)
> Jan 6 05:03:56 thefinal kernel: e820: 00010000 @ 03ff0000 (reserved)
> Jan 6 05:03:56 thefinal kernel: e820: 00016e00 @ 100a0000 (reserved)
> Jan 6 05:03:56 thefinal kernel: e820: 00000200 @ 100b6e00 (ACPI NVS)
> Jan 6 05:03:56 thefinal kernel: e820: 00049000 @ 100b7000 (reserved)
> Jan 6 05:03:56 thefinal kernel: e820: 00080000 @ fff80000 (reserved)
>
> The map looks plausible to me. How do I tell which page ranges the
> kernel is using for memory allocation?
>
> -- 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/
-
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:08 EST