slow last 128MB of RAM in a 2GB system?

Michael ODonnell michael.odonnell at comcast.net
Thu Apr 19 13:48:50 EDT 2007



As long as this thread involves MTRR and e820 dumps...

We have a number of Dell Precision 690 boxes with 4 1Gb DIMMs
installed but our RHAT WS3 kernel is only willing to acknowledge
3Gb and I'm trying to figure out why.  We have a number of these
machines so I claim that it's not just one system or just one
DIMM.  After the system is booted /proc/mtrr looks like this:

> reg00: base=0x00000000  (0MB),     size=65536MB: write-back, count=1
> reg01: base=0xbff00000  (3071MB),  size=1MB:     uncachable, count=1
> reg02: base=0xc0000000  (3072MB),  size=1024MB:  uncachable, count=1
> reg03: base=0xff0000000 (65280MB), size=256MB:   uncachable, count=1

...and its e820 map is reported (along with resultant calculations)
by the kernel thus:

> Linux version 2.4.21-47.EL-smp (root at qwerty) (gcc version 3.2.3 20030502
>     (Red Hat Linux 3.2.3-56)) #8 SMP Wed Jan 31 11:12:28 EST 2007
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 000000000009e400 (usable)
>  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 00000000bfe0ac00 (usable)
>  BIOS-e820: 00000000bfe0ac00 - 00000000bfe0cc00 (ACPI NVS)
>  BIOS-e820: 00000000bfe0ec00 - 00000000bfe5cc00 (reserved)
>  BIOS-e820: 00000000bfe5cc00 - 00000000bfe5ec00 (ACPI data)
>  BIOS-e820: 00000000bfe5ec00 - 00000000c0000000 (reserved)
>  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  BIOS-e820: 00000000fe000000 - 00000000ff000000 (reserved)
>  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
>  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
> user-defined physical RAM map:
>  user: 0000000000000000 - 000000000009e400 (usable)
>  user: 00000000000f0000 - 0000000000100000 (reserved)
>  user: 0000000000100000 - 00000000bfe0ac00 (usable)
>  user: 00000000bfe0ac00 - 00000000bfe0cc00 (ACPI NVS)
>  user: 00000000bfe0ec00 - 00000000bfe5cc00 (reserved)
>  user: 00000000bfe5cc00 - 00000000bfe5ec00 (ACPI data)
>  user: 00000000bfe5ec00 - 00000000c0000000 (reserved)
>  user: 00000000e0000000 - 00000000f0000000 (reserved)
>  user: 00000000fe000000 - 00000000ff000000 (reserved)
>  user: 00000000ffb00000 - 0000000100000000 (reserved)
>  user: 0000000100000000 - 0000000100000000 (usable)
> 0MB HIGHMEM available.
> 3070MB LOWMEM available.
> found SMP MP-table at 000fe710
> hm, page 000fe000 reserved twice.
> hm, page 000ff000 reserved twice.
> hm, page 000f0000 reserved twice.
> NX protection not present; using segment protection
> On node 0 totalpages: 785930
> zone(0): 4096 pages.
> zone(1): 781834 pages.
> zone(2): 0 pages.
>
> ACPI: Searched entire block, no RSDP was found.
> ACPI: RSDP located at physical address 020febf0
> RSD PTR  v2 [DELL  ]
> __va_range(0xfcde8, 0x24): idx=9 mapped at ffff5000
	.
	.
	.
> Enabling APIC mode: Flat.       Using 2 I/O APICs
> Kernel command line: ro root=LABEL=/ mem=4096M
> mapped 4G/4G trampoline to fffef000.
> Initializing CPU#0
> Detected 3724.061 MHz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 7418.67 BogoMIPS
> Page-cache hash table entries: 1048576 (order: 10, 4096 KB)
> Page-pin hash table entries: 262144 (order: 8, 1024 KB)
> Dentry cache hash table entries: 524288 (order: 10, 4096 KB)
> Inode cache hash table entries: 262144 (order: 9, 2048 KB)
> Buffer cache hash table entries: 262144 (order: 8, 1024 KB)
> Memory: 3080852k/3143720k available (1887k kernel code, 60300k
>                   reserved, 1424k data, 216k init, 0k highmem)


...so it seems like right around the 3Gb mark the BIOS has
marked the next 1Gb as "uncachable" or "reserved" and the kernel
(I'm guessing) is honoring that by pretending it's not there.
FWIW, memtest86+ reports (and is apparently happy with) all 4Gb.

I'd be much obliged for any illumination, or even whacks from
a clue-stick...
 


More information about the gnhlug-discuss mailing list