BIOS detects 4 GB RAM, but kernel does not
in [General Linux]
|
Prev: Create Linux FC SAN Target
Next: top - high load
From: ravibt on 26 Jul 2006 12:27 Hello, On a dual core Pentium 4 EM64T machine (Intel Desktop Board D915GAV), we used four 1GB RAM (DDR 400) modules. The BIOS (EV91510A.86A.0444) detected all the four 1 GB modules, but once the OS is booted, only ~3.1GB is available for usage (from dmesg: "Memory: 3210516k/3267772k available"; see below). The kernel used is version 2.6.9-22.ELsmp coming with 'CentOS release 4.2 Final'. [The four RAM modules have been tested OK with the 'memtest']. Using "mem=4096m" while booting the kernel also did not help. Searched through the old messages and it looks like in most of the cases enabling some memory-hole related option in BIOS is suggested, but in this case probably the BIOS is fine. Not sure if some kernel configuration option is missing or if someother version of the kernel needs to be used. This being a 64 bit machine, we expected memory-remap to be happening. Is there a way in which ~900 MB of RAM can be made usable? Any pointers will be of great help. Please let me know if more information is needed than the following transcripts (/proc/iomem and dmesg): $ more /proc/iomem 00000000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000f0000-000fffff : System ROM 00100000-c772fbff : System RAM 00100000-0030754e : Kernel code 0030754f-0044680d : Kernel data c772fc00-c772ffff : ACPI Non-volatile Storage c7730000-c773ffff : ACPI Tables c7740000-c77effff : ACPI Non-volatile Storage c77f0000-c77fffff : reserved cfb00000-cfbfffff : PCI Bus #05 cfc00000-cfcfffff : PCI Bus #04 cfd00000-cfdfffff : PCI Bus #03 cfe00000-cfefffff : PCI Bus #02 cff00000-cfffffff : PCI Bus #01 d0000000-dfffffff : 0000:00:02.0 e0000000-efffffff : reserved fed13000-fed19fff : reserved fed1c000-fed9ffff : reserved ff43bc00-ff43bfff : 0000:00:1d.7 ff43bc00-ff43bfff : ehci_hcd ff43c000-ff43ffff : 0000:00:1b.0 ff43c000-ff43ffff : ICH HD audio ff440000-ff47ffff : 0000:00:02.0 ff480000-ff4fffff : 0000:00:02.0 ff500000-ff500fff : 0000:06:08.0 ff500000-ff500fff : e100 ff600000-ff6fffff : PCI Bus #05 ff700000-ff7fffff : PCI Bus #04 ff800000-ff8fffff : PCI Bus #03 ff900000-ff9fffff : PCI Bus #02 ffa00000-ffafffff : PCI Bus #01 $ dmesg Bootdata ok (command line is ro root=LABEL=/1 mem=4096m rhgb quiet) Linux version 2.6.9-22.ELsmp (buildcentos(a)monk.karan.org) (gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)) #1 SMP Sat Oct 8 21:32:36 BST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000c772fc00 (usable) BIOS-e820: 00000000c772fc00 - 00000000c7730000 (ACPI NVS) BIOS-e820: 00000000c7730000 - 00000000c7740000 (ACPI data) BIOS-e820: 00000000c7740000 - 00000000c77f0000 (ACPI NVS) BIOS-e820: 00000000c77f0000 - 00000000c7800000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fed13000 - 00000000fed1a000 (reserved) BIOS-e820: 00000000fed1c000 - 00000000feda0000 (reserved) ACPI: RSDP (v000 ACPIAM ) @ 0x00000000000f4eb0 ACPI: RSDT (v001 INTEL D915GAV 0x20050429 MSFT 0x00000097) @ 0x00000000c7730000 ACPI: FADT (v002 INTEL D915GAV 0x20050429 MSFT 0x00000097) @ 0x00000000c7730200 ACPI: MADT (v001 INTEL D915GAV 0x20050429 MSFT 0x00000097) @ 0x00000000c7730390 ACPI: MCFG (v001 INTEL D915GAV 0x20050429 MSFT 0x00000097) @ 0x00000000c7730400 ACPI: ASF! (v016 LEGEND I865PASF 0x00000001 INTL 0x02002026) @ 0x00000000c7736020 ACPI: TCPA (v001 INTEL TBLOEMID 0x00000001 MSFT 0x00000097) @ 0x00000000c77360c0 ACPI: WDDT (v001 INTEL OEMWDDT 0x00000001 INTL 0x02002026) @ 0x00000000c77360f4 ACPI: DSDT (v001 INTEL D915GAV 0x00000001 INTL 0x02002026) @ 0x0000000000000000 No NUMA configuration found Faking a node at 0000000000000000-00000000c772f000 Bootmem setup node 0 0000000000000000-00000000c772f000 No mptable found. On node 0 totalpages: 816943 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 812847 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) Setting APIC routing to flat ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information Checking aperture... Built 1 zonelists Kernel command line: ro root=LABEL=/1 mem=4096m rhgb quiet console=tty0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 3.579545 MHz PM timer. time.c: Detected 3000.257 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Memory: 3210516k/3267772k available (2077k kernel code, 0k reserved, 1276k data, 188k init) Calibrating delay loop... 5914.62 BogoMIPS (lpj=2957312) Security Scaffold v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode There is already a security framework initialized, register_security failed. selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K using mwait in idle threads. CPU0: Initial APIC ID: 0, Physical Processor ID: 0 Using IO APIC NMI watchdog CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K CPU0: Initial APIC ID: 0, Physical Processor ID: 0 CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03 per-CPU timeslice cutoff: 615.86 usecs. task migration cache decay timeout: 1 msecs. Booting processor 1/1 rip 6000 rsp 100042d5f58 Initializing CPU#1 Calibrating delay loop
From: iforone on 26 Jul 2006 13:08 ravibt(a)gmail.com wrote: > Hello, > > On a dual core Pentium 4 EM64T machine (Intel Desktop Board D915GAV), > we used four 1GB RAM (DDR 400) modules. The BIOS (EV91510A.86A.0444) > detected all the four 1 GB modules, but once the OS is booted, only > ~3.1GB is available for usage (from dmesg: "Memory: 3210516k/3267772k > available"; see below). The kernel used is version 2.6.9-22.ELsmp > coming with 'CentOS release 4.2 Final'. > [The four RAM modules have been tested OK with the 'memtest']. > > Using "mem=4096m" while booting the kernel also did not help. Searched > through the old messages and it looks like in most of the cases > enabling some memory-hole related option in BIOS is suggested, but in > this case probably the BIOS is fine. Not sure if some kernel > configuration option is missing or if someother version of the kernel > needs to be used. > > This being a 64 bit machine, we expected memory-remap to be happening. > Is there a way in which ~900 MB of RAM can be made usable? > Any pointers will be of great help. > > Please let me know if more information is needed than the following > transcripts (/proc/iomem and dmesg): <snipped> What's ther output of; ~$ grep CONFIG_HIGH /boot/config-2.6.9-22.ELsmp CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set
From: ravibt on 27 Jul 2006 09:36 > What's ther output of; > > ~$ grep CONFIG_HIGH /boot/config-2.6.9-22.ELsmp Nothing. Browsed through the 'Kconfig' files in the src tree and found that HIGHMEM* options are available for i386 arch only, and in this case x86_64 is being used. As an aside, we have another similar dual core intel pentium4 machine with one difference: 32 bit instead of 64 bit with the same problem: BIOS detects 4 GB RAM but kernel reports ~3.1GB. In this one, `grep HIGHMEM /boot/config-2.6.17.7_20060727` (Note: different kernel) gives the following output: # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_DEBUG_HIGHMEM=y [This 32 bit machine had reported ~3.1GB RAM with kernel 2.6.9-34.ELsmp (CentOS 4.3 Final) too.] Also, I tried using a different kernel (2.6.17.1) in the 64 bit machine with the same result. As Robert Hancock has explained, probably nothing can be done about it!! Thanks very much both of you for the quick responses! regards, Ravi.
From: Jean-David Beyer on 27 Jul 2006 10:01 ravibt(a)gmail.com wrote: >> What's ther output of; >> >> ~$ grep CONFIG_HIGH /boot/config-2.6.9-22.ELsmp > > Nothing. > > Browsed through the 'Kconfig' files in the src tree and found that > HIGHMEM* options are available for i386 arch only, and in this case > x86_64 is being used. > > > As an aside, we have another similar dual core intel pentium4 machine > with one difference: 32 bit instead of 64 bit with the same problem: > BIOS detects 4 GB RAM but kernel reports ~3.1GB. In this one, `grep > HIGHMEM /boot/config-2.6.17.7_20060727` (Note: different kernel) gives > the following output: > # CONFIG_NOHIGHMEM is not set > CONFIG_HIGHMEM4G=y > # CONFIG_HIGHMEM64G is not set > CONFIG_HIGHMEM=y > CONFIG_DEBUG_HIGHMEM=y > [This 32 bit machine had reported ~3.1GB RAM with kernel 2.6.9-34.ELsmp > (CentOS 4.3 Final) too.] > > Also, I tried using a different kernel (2.6.17.1) in the 64 bit machine > with the same result. > > As Robert Hancock has explained, probably nothing can be done about > it!! > > Thanks very much both of you for the quick responses! > > regards, > Ravi. > You need to compile with # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y CONFIG_X86_PAE=y CONFIG_HIGHIO=y CONFIG_X86_4G=y CONFIG_X86_SWITCH_PAGETABLES=y CONFIG_X86_4G_VM_LAYOUT=y CONFIG_X86_UACCESS_INDIRECT=y CONFIG_X86_HIGH_ENTRY=y in your .config (for *86 machines) to get 4G of user and 4G of system space. I so or know how much sense this would make for a 4G of RAM machine. I never tried it when this machine had only 4G, but that is what is required to get all 4G in a single user process now that I have 8G. -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jersey http://counter.li.org ^^-^^ 09:40:01 up 6 days, 16:18, 3 users, load average: 4.33, 4.36, 4.30
From: General Schvantzkoph on 27 Jul 2006 11:45
On Wed, 26 Jul 2006 09:27:58 -0700, ravibt wrote: > Hello, > > On a dual core Pentium 4 EM64T machine (Intel Desktop Board D915GAV), > we used four 1GB RAM (DDR 400) modules. The BIOS (EV91510A.86A.0444) > detected all the four 1 GB modules, but once the OS is booted, only > ~3.1GB is available for usage (from dmesg: "Memory: 3210516k/3267772k > available"; see below). The kernel used is version 2.6.9-22.ELsmp > coming with 'CentOS release 4.2 Final'. > [The four RAM modules have been tested OK with the 'memtest']. > > Using "mem=4096m" while booting the kernel also did not help. Searched > through the old messages and it looks like in most of the cases > enabling some memory-hole related option in BIOS is suggested, but in > this case probably the BIOS is fine. Not sure if some kernel > configuration option is missing or if someother version of the kernel > needs to be used. > > This being a 64 bit machine, we expected memory-remap to be happening. > Is there a way in which ~900 MB of RAM can be made usable? > Any pointers will be of great help. > > Please let me know if more information is needed than the following > transcripts (/proc/iomem and dmesg): This could be a memory hole remapping issue. The old way of mapping the IO space was to map in in the upper part of the 4G memory space, that's still the default. Check your BIOS to see if there is something called Memory Hole Remapping (that's what it's called on my MSI K8N Neo4 Athlon64 board, it may be called something different on your P4 board). If you find something like that enable it. You will also need a recent kernel, the IOMMU code prior to 2.6.15 doesn't work. |