Tigran, trust me. There are subtle issues throughout the initialization
code which need to be corrected or cleaned up. It's taken me >400 hrs to go
from 0 knowlege to where I am, and I'm not generally considered a slow
learner. Parsons and I are in communication on these issues--we may even
offer a joint patch. I know that yours has been a frustrating problem, and
I can only apologized that I was so sloppy as to assume that code which was
aware of the issue at one point was aware 20 lines earlier.
But this patch will be worth waiting for. (For you--we are NOT going to ask
Linus to wait on us!)
Nathan
-----Original Message-----
From: Tigran Aivazian [mailto:tigran@sco.COM]
Sent: Thursday, December 16, 1999 2:51 AM
To: Zook, Nathan
Cc: torvalds@transmeta.com; linux-kernel@vger.rutgers.edu
Subject: RE: [patch-2.3.33] memory size on proliant/1600
Hi Nathan and Linus,
> Note that this patch does NOT properly drop a region which, for instance,
> begins at 0x80000000 of length 512, because it's length is NOT zero (until
> we page align it.) Such regions may in fact exist as left-overs from ACPI
> or NVS regions.
ACPI regions would be of type E820_ACPI and thus skipped automatically.
However, you are right, on Intel platforms having less than a page of
memory is like having no memory at all, see patch below. Is this one
acceptable now?
--- linux/arch/i386/kernel/setup.c Wed Dec 8 07:01:40 1999
+++ work/arch/i386/kernel/setup.c Thu Dec 16 09:38:54 1999
@@ -594,7 +594,7 @@
for (i = 0; i < e820.nr_map; i++) {
unsigned long curr_pfn;
/* RAM? */
- if (e820.map[i].type != E820_RAM)
+ if (e820.map[i].type != E820_RAM ||
PFN_DOWN(e820.map[i].size) == 0)
continue;
curr_pfn = PFN_DOWN(e820.map[i].addr + e820.map[i].size);
if (curr_pfn > max_pfn)
-
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/