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 ([EMAIL PROTECTED]) (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... _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/