RE: [patch-2.3.33] memory size on proliant/1600

Tigran Aivazian (tigran@sco.COM)
Thu, 16 Dec 1999 16:14:33 +0000 (GMT)


Ok, I admit my e820 knowledge is not 400 hours but only 17 minutes that it
took me to produce the simple workaround/fix for my specific problem with
this specific Proliant/1600. So I trust you and defer to you to produce a
more complete solution.

David Parsons sent me a patch but it did not work "out-of-the-box" and I
did not have time to fix it (I am at work, you know ;)

I obviously look forward to see your+David's solution that works in all
cases.

Thank you,
------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran

On Thu, 16 Dec 1999 nathan.zook@amd.com wrote:

> No. Suppose a region began at 0x7fffff00 and ended at 0x80000100.
>
> 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/