lkml.org 
[lkml]   [1999]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRE: [patch-2.3.33] memory size on proliant/1600 (was Re: Ok, maki ng , ready for pre-2.4 and code-freeze..)
Date
Hmm..  Didn't there used to be a check in the code for post-page-aligned
zero-length regions? If not, that explains your problem, as well as why I
couldn't find it. :-))

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.

And yes, I'm on it...

Nathan


-----Original Message-----
From: Tigran Aivazian [mailto:tigran@sco.COM]
Sent: Wednesday, December 15, 1999 10:15 AM
To: torvalds@transmeta.com
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: [patch-2.3.33] memory size on proliant/1600 (was Re: Ok,
making , ready for pre-2.4 and code-freeze..)


On Wed, 15 Dec 1999, Tigran Aivazian wrote:
> --- linux/arch/i386/kernel/setup.c Wed Dec 8 07:01:40 1999
> +++ ta/arch/i386/kernel/setup.c Wed Dec 15 15:41:06 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 || (int)e820.map[i].size ==
0)
> continue;
> curr_pfn = PFN_DOWN(e820.map[i].addr + e820.map[i].size);
> if (curr_pfn > max_pfn)

Just to confirm that the above is the *right* fix (despite some doubts I
had for a minute), the e820 map as discovered during boot on this hardware
looks like this (using gdb -q vmlinux /proc/kcore):

(gdb) p e820
$3 = {nr_map = 0x8, map = {{addr = 0x0, size = 0x9f800, type = 0x1}, {addr
= 0x9f800,
size = 0x800, type = 0x2}, {addr = 0xf0000, size = 0x10000, type =
0x2}, {addr = 0x100000,
size = 0x3f00000, type = 0x1}, {addr = 0xfec00000, size = 0x10000,
type = 0x2}, {
addr = 0xfee00000, size = 0x10000, type = 0x2}, {addr = 0xfff80000,
size = 0x80000,
type = 0x2}, {addr = 0x100000000, size = 0x0, type = 0x1}, {addr =
0x0, size = 0x0,
type = 0x0} <repeats 24 times>}}

so, the entry e820[7] is definitely bogus (addr = 0x100000000) and is best
avoided and not counted as valid E820_RAM...
Regards,
Tigran.





-
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.044 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site