Hi everyone.
I am having some difficulty trying to get my 4Gb of ram recognized by
the system. I have tried googling around to get some information on how
to do this configuration, but I have come up dry. I suspect that the
reason that there is not much info on how to set things up is because
usually it just works. However, on my system I don't think it is.
By the way, I am not subscribed to this mailing list, so could you
please CC me any replies.
The basics are that I have an Athlon 64 X2 Dual core, 4Gb ram, ASUS
M2N-MX motherboard. The bios has a configuration item for MTRR mapping,
with options for CONTINUOUS and DISCRETE. I have selected CONTINUOUS,
which explicitly describes the PCI hole as non-cacheable. The other
option leaves the PCI hole undescribed.
My config has selected
CONFIG_HIGHMEM4G=y
free -m reports the following....
total used free shared buffers cached
Mem: 2906 2794 112 0 275 31
-/+ buffers/cache: 2487 419
Swap: 4996 366 4630
/proc/mtrr contains the following....
reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
Relevant bootup messages include these....
Jun 3 13:50:52 fawkes Linux version 2.6.20-gentoo-r8 (root@fawkes) (gcc
version 4.1.1 (Gentoo 4.1.1-r3)) #6 SMP Tue May 15 10:18:59 EDT 2007
Jun 3 13:50:52 fawkes BIOS-provided physical RAM map:
Jun 3 13:50:52 fawkes sanitize start
Jun 3 13:50:52 fawkes sanitize end
Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000000000000 size:
000000000009fc00 end: 000000000009fc00 type: 1
Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
Jun 3 13:50:52 fawkes copy_e820_map() start: 000000000009fc00 size:
0000000000000400 end: 00000000000a0000 type: 2
Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000000e0000 size:
0000000000020000 end: 0000000000100000 type: 2
Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000000100000 size:
00000000b7ec0000 end: 00000000b7fc0000 type: 1
Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7fc0000 size:
000000000000e000 end: 00000000b7fce000 type: 3
Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7fce000 size:
0000000000022000 end: 00000000b7ff0000 type: 4
Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7ff0000 size:
0000000000010000 end: 00000000b8000000 type: 2
Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000fec00000 size:
0000000000001000 end: 00000000fec01000 type: 2
Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000fee00000 size:
0000000000100000 end: 00000000fef00000 type: 2
Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000ff780000 size:
0000000000880000 end: 0000000100000000 type: 2
Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000100000000 size:
0000000040000000 end: 0000000140000000 type: 1
Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
Jun 3 13:50:52 fawkes BIOS-e820: 0000000000000000 - 000000000009fc00
(usable)
Jun 3 13:50:52 fawkes BIOS-e820: 000000000009fc00 - 00000000000a0000
(reserved)
Jun 3 13:50:52 fawkes BIOS-e820: 00000000000e0000 - 0000000000100000
(reserved)
Jun 3 13:50:52 fawkes BIOS-e820: 0000000000100000 - 00000000b7fc0000
(usable)
Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7fc0000 - 00000000b7fce000
(ACPI data)
Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7fce000 - 00000000b7ff0000
(ACPI NVS)
Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7ff0000 - 00000000b8000000
(reserved)
Jun 3 13:50:52 fawkes BIOS-e820: 00000000fec00000 - 00000000fec01000
(reserved)
Jun 3 13:50:52 fawkes BIOS-e820: 00000000fee00000 - 00000000fef00000
(reserved)
Jun 3 13:50:52 fawkes BIOS-e820: 00000000ff780000 - 0000000100000000
(reserved)
Jun 3 13:50:52 fawkes BIOS-e820: 0000000100000000 - 0000000140000000
(usable)
Jun 3 13:50:52 fawkes Warning only 4GB will be used.
Jun 3 13:50:52 fawkes Use a PAE enabled kernel.
Jun 3 13:50:52 fawkes 3200MB HIGHMEM available.
Jun 3 13:50:52 fawkes 896MB LOWMEM available.
Jun 3 13:50:52 fawkes found SMP MP-table at 000ff780
Jun 3 13:50:52 fawkes Entering add_active_range(0, 0, 1048576) 0
entries of 256 used
Jun 3 13:50:52 fawkes Zone PFN ranges:
Jun 3 13:50:52 fawkes DMA 0 -> 4096
Jun 3 13:50:52 fawkes Normal 4096 -> 229376
Jun 3 13:50:52 fawkes HighMem 229376 -> 1048576
Jun 3 13:50:52 fawkes early_node_map[1] active PFN ranges
Jun 3 13:50:52 fawkes 0: 0 -> 1048576
Jun 3 13:50:52 fawkes On node 0 totalpages: 1048576
Jun 3 13:50:52 fawkes DMA zone: 32 pages used for memmap
Jun 3 13:50:52 fawkes DMA zone: 0 pages reserved
Jun 3 13:50:52 fawkes DMA zone: 4064 pages, LIFO batch:0
Jun 3 13:50:52 fawkes Normal zone: 1760 pages used for memmap
Jun 3 13:50:52 fawkes Normal zone: 223520 pages, LIFO batch:31
Jun 3 13:50:52 fawkes HighMem zone: 6400 pages used for memmap
Jun 3 13:50:52 fawkes HighMem zone: 812800 pages, LIFO batch:31
Jun 3 13:50:52 fawkes DMI 2.3 present.
Jun 3 13:50:52 fawkes Using APIC driver default
Jun 3 13:50:52 fawkes ACPI: RSDP (v002
ACPIAM ) @ 0x000fbab0
Jun 3 13:50:52 fawkes ACPI: XSDT (v001 A M I OEMXSDT 0x09000606 MSFT
0x00000097) @ 0xb7fc0100
Jun 3 13:50:52 fawkes ACPI: FADT (v003 A M I OEMFACP 0x09000606 MSFT
0x00000097) @ 0xb7fc0290
Jun 3 13:50:52 fawkes ACPI: MADT (v001 A M I OEMAPIC 0x09000606 MSFT
0x00000097) @ 0xb7fc0390
Jun 3 13:50:52 fawkes ACPI: MCFG (v001 A M I OEMMCFG 0x09000606 MSFT
0x00000097) @ 0xb7fc0400
Jun 3 13:50:52 fawkes ACPI: OEMB (v001 A M I AMI_OEM 0x09000606 MSFT
0x00000097) @ 0xb7fce040
Jun 3 13:50:52 fawkes ACPI: SSDT (v001 A M I POWERNOW 0x00000001 AMD
0x00000001) @ 0xb7fc5300
Jun 3 13:50:52 fawkes ACPI: DSDT (v001 A0557 A0557000 0x00000000 INTL
0x02002026) @ 0x00000000
Jun 3 13:50:52 fawkes Nvidia board detected. Ignoring ACPI timer override.
Jun 3 13:50:52 fawkes If you got timer trouble try acpi_use_timer_override
Jun 3 13:50:52 fawkes Nvidia board detected. Ignoring ACPI timer override.
Jun 3 13:50:52 fawkes If you got timer trouble try acpi_use_timer_override
Jun 3 13:50:52 fawkes Nvidia board detected. Ignoring ACPI timer override.
Jun 3 13:50:52 fawkes If you got timer trouble try acpi_use_timer_override
Jun 3 13:50:52 fawkes Nvidia board detected. Ignoring ACPI timer override.
Jun 3 13:50:52 fawkes If you got timer trouble try acpi_use_timer_override
Jun 3 13:50:52 fawkes ACPI: PM-Timer IO Port: 0x508
Jun 3 13:50:52 fawkes ACPI: Local APIC address 0xfee00000
Jun 3 13:50:52 fawkes ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Jun 3 13:50:52 fawkes Processor #0 15:11 APIC version 16
Jun 3 13:50:52 fawkes ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Jun 3 13:50:52 fawkes Processor #1 15:11 APIC version 16
Jun 3 13:50:52 fawkes ACPI: IOAPIC (id[0x02] address[0xfec00000]
gsi_base[0])
Jun 3 13:50:52 fawkes IOAPIC[0]: apic_id 2, version 17, address
0xfec00000, GSI 0-23
Jun 3 13:50:52 fawkes ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0
dfl dfl)
Jun 3 13:50:52 fawkes ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9
high level)
Jun 3 13:50:52 fawkes ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14
high edge)
Jun 3 13:50:52 fawkes ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15
high edge)
Jun 3 13:50:52 fawkes ACPI: IRQ0 used by override.
Jun 3 13:50:52 fawkes ACPI: IRQ9 used by override.
Jun 3 13:50:52 fawkes ACPI: IRQ14 used by override.
Jun 3 13:50:52 fawkes ACPI: IRQ15 used by override.
Jun 3 13:50:52 fawkes Enabling APIC mode: Flat. Using 1 I/O APICs
Jun 3 13:50:52 fawkes Using ACPI (MADT) for SMP configuration information
Jun 3 13:50:52 fawkes Allocating PCI resources starting at c0000000
(gap: b8000000:46c00000)
Jun 3 13:50:52 fawkes Detected 2009.188 MHz processor.
Jun 3 13:50:52 fawkes Built 1 zonelists. Total pages: 1040384
Jun 3 13:50:52 fawkes Kernel command line: root=/dev/sda2
Jun 3 13:50:52 fawkes mapped APIC to ffffd000 (fee00000)
Jun 3 13:50:52 fawkes mapped IOAPIC to ffffc000 (fec00000)
Jun 3 13:50:52 fawkes Enabling fast FPU save and restore... done.
Jun 3 13:50:52 fawkes Enabling unmasked SIMD FPU exception support... done.
Jun 3 13:50:52 fawkes Initializing CPU#0
Jun 3 13:50:52 fawkes PID hash table entries: 4096 (order: 12, 16384 bytes)
Jun 3 13:50:52 fawkes spurious 8259A interrupt: IRQ7.
Jun 3 13:50:52 fawkes Console: colour VGA+ 80x25
Jun 3 13:50:52 fawkes Dentry cache hash table entries: 131072 (order:
7, 524288 bytes)
Jun 3 13:50:52 fawkes Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Jun 3 13:50:52 fawkes Memory: 2975372k/4194304k available (2686k kernel
code, 37964k reserved, 935k data, 272k init, 2096896k highmem)
Jun 3 13:50:52 fawkes virtual kernel memory layout:
Jun 3 13:50:52 fawkes fixmap : 0xfff9c000 - 0xfffff000 ( 396 kB)
Jun 3 13:50:52 fawkes pkmap : 0xff800000 - 0xffc00000 (4096 kB)
Jun 3 13:50:52 fawkes vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB)
Jun 3 13:50:52 fawkes lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
Jun 3 13:50:52 fawkes .init : 0xc0491000 - 0xc04d5000 ( 272 kB)
Jun 3 13:50:52 fawkes .data : 0xc039fa7d - 0xc0489a18 ( 935 kB)
Jun 3 13:50:52 fawkes .text : 0xc0100000 - 0xc039fa7d (2686 kB)
Any suggestions as to what I can try to get all 4Gb of ram to show up?
Thanks,
Tom
On Mon, Jun 04, 2007 at 11:14:40AM -0400, Tom Moore wrote:
> I am having some difficulty trying to get my 4Gb of ram recognized by
> the system. I have tried googling around to get some information on how
> to do this configuration, but I have come up dry. I suspect that the
> reason that there is not much info on how to set things up is because
> usually it just works. However, on my system I don't think it is.
>
> By the way, I am not subscribed to this mailing list, so could you
> please CC me any replies.
>
> The basics are that I have an Athlon 64 X2 Dual core, 4Gb ram, ASUS
> M2N-MX motherboard. The bios has a configuration item for MTRR mapping,
> with options for CONTINUOUS and DISCRETE. I have selected CONTINUOUS,
> which explicitly describes the PCI hole as non-cacheable. The other
> option leaves the PCI hole undescribed.
>
> My config has selected
> CONFIG_HIGHMEM4G=y
That supports of to 4GB memory space.
> free -m reports the following....
> total used free shared buffers cached
> Mem: 2906 2794 112 0 275 31
> -/+ buffers/cache: 2487 419
> Swap: 4996 366 4630
>
>
> /proc/mtrr contains the following....
>
> reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
Your memory map however has 3GB at address 0 and 1GB at address 4GB (so
memory is places at address 0 - 3GB and 4-5GB. The addresses from 3 to
4GB are reserved for PCI).
If you run a 64bit kernel you will see it all, or you can use a kernel
configured for 64GB memory space.
> Relevant bootup messages include these....
> Jun 3 13:50:52 fawkes Linux version 2.6.20-gentoo-r8 (root@fawkes) (gcc
> version 4.1.1 (Gentoo 4.1.1-r3)) #6 SMP Tue May 15 10:18:59 EDT 2007
> Jun 3 13:50:52 fawkes BIOS-provided physical RAM map:
> Jun 3 13:50:52 fawkes sanitize start
> Jun 3 13:50:52 fawkes sanitize end
> Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000000000000 size:
> 000000000009fc00 end: 000000000009fc00 type: 1
> Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
> Jun 3 13:50:52 fawkes copy_e820_map() start: 000000000009fc00 size:
> 0000000000000400 end: 00000000000a0000 type: 2
> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000000e0000 size:
> 0000000000020000 end: 0000000000100000 type: 2
> Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000000100000 size:
> 00000000b7ec0000 end: 00000000b7fc0000 type: 1
> Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7fc0000 size:
> 000000000000e000 end: 00000000b7fce000 type: 3
> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7fce000 size:
> 0000000000022000 end: 00000000b7ff0000 type: 4
> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7ff0000 size:
> 0000000000010000 end: 00000000b8000000 type: 2
> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000fec00000 size:
> 0000000000001000 end: 00000000fec01000 type: 2
> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000fee00000 size:
> 0000000000100000 end: 00000000fef00000 type: 2
> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000ff780000 size:
> 0000000000880000 end: 0000000100000000 type: 2
> Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000100000000 size:
> 0000000040000000 end: 0000000140000000 type: 1
> Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
> Jun 3 13:50:52 fawkes BIOS-e820: 0000000000000000 - 000000000009fc00
> (usable)
> Jun 3 13:50:52 fawkes BIOS-e820: 000000000009fc00 - 00000000000a0000
> (reserved)
> Jun 3 13:50:52 fawkes BIOS-e820: 00000000000e0000 - 0000000000100000
> (reserved)
> Jun 3 13:50:52 fawkes BIOS-e820: 0000000000100000 - 00000000b7fc0000
> (usable)
> Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7fc0000 - 00000000b7fce000
> (ACPI data)
> Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7fce000 - 00000000b7ff0000
> (ACPI NVS)
> Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7ff0000 - 00000000b8000000
> (reserved)
> Jun 3 13:50:52 fawkes BIOS-e820: 00000000fec00000 - 00000000fec01000
> (reserved)
> Jun 3 13:50:52 fawkes BIOS-e820: 00000000fee00000 - 00000000fef00000
> (reserved)
> Jun 3 13:50:52 fawkes BIOS-e820: 00000000ff780000 - 0000000100000000
> (reserved)
> Jun 3 13:50:52 fawkes BIOS-e820: 0000000100000000 - 0000000140000000
> (usable)
> Jun 3 13:50:52 fawkes Warning only 4GB will be used.
> Jun 3 13:50:52 fawkes Use a PAE enabled kernel.
Oh look, it even tells you right there that you have to use a PAE (>4GB
for 32bit machines) kernel to get all your ram.
--
Len Sorensen
Thank you for the reply back. Your answer makes perfect sense to me,
and it is what I had suspected but was not sure about. The math seems
to indicate that 4Gb of ram plus 1Gb of PCI address space equals 5Gb of
memory space. So it does sound like I should have a larger kernel model.
What confused me the most (and still does), is the help message string
that is presented for the CONFIG_HIGHMEM4G option:
"Select this if you have a 32-bit processor and between 1 and 4
gigabytes of physical RAM."
Well that sounds like the amount of memory that I have, so that is what
I selected.
Also, although I know what PAE stands for, I don't know how to select it
when building a kernel. Would I get this from the CONFIG_HIGHMEM64G
option? The help text for that says:
"Select this if you have a 32-bit processor and more than 4 gigabytes
of physical RAM."
This does not sound like it applies to my hardware. There is something
wrong with my understanding, or with these message strings. I am still
confused.
Tom
Lennart Sorensen wrote:
> On Mon, Jun 04, 2007 at 11:14:40AM -0400, Tom Moore wrote:
>
>> I am having some difficulty trying to get my 4Gb of ram recognized by
>> the system. I have tried googling around to get some information on how
>> to do this configuration, but I have come up dry. I suspect that the
>> reason that there is not much info on how to set things up is because
>> usually it just works. However, on my system I don't think it is.
>>
>> By the way, I am not subscribed to this mailing list, so could you
>> please CC me any replies.
>>
>> The basics are that I have an Athlon 64 X2 Dual core, 4Gb ram, ASUS
>> M2N-MX motherboard. The bios has a configuration item for MTRR mapping,
>> with options for CONTINUOUS and DISCRETE. I have selected CONTINUOUS,
>> which explicitly describes the PCI hole as non-cacheable. The other
>> option leaves the PCI hole undescribed.
>>
>> My config has selected
>> CONFIG_HIGHMEM4G=y
>>
>
> That supports of to 4GB memory space.
>
>
>> free -m reports the following....
>> total used free shared buffers cached
>> Mem: 2906 2794 112 0 275 31
>> -/+ buffers/cache: 2487 419
>> Swap: 4996 366 4630
>>
>>
>> /proc/mtrr contains the following....
>>
>> reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>> reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>>
>
> Your memory map however has 3GB at address 0 and 1GB at address 4GB (so
> memory is places at address 0 - 3GB and 4-5GB. The addresses from 3 to
> 4GB are reserved for PCI).
>
> If you run a 64bit kernel you will see it all, or you can use a kernel
> configured for 64GB memory space.
>
>
>> Relevant bootup messages include these....
>> Jun 3 13:50:52 fawkes Linux version 2.6.20-gentoo-r8 (root@fawkes) (gcc
>> version 4.1.1 (Gentoo 4.1.1-r3)) #6 SMP Tue May 15 10:18:59 EDT 2007
>> Jun 3 13:50:52 fawkes BIOS-provided physical RAM map:
>> Jun 3 13:50:52 fawkes sanitize start
>> Jun 3 13:50:52 fawkes sanitize end
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000000000000 size:
>> 000000000009fc00 end: 000000000009fc00 type: 1
>> Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 000000000009fc00 size:
>> 0000000000000400 end: 00000000000a0000 type: 2
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000000e0000 size:
>> 0000000000020000 end: 0000000000100000 type: 2
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000000100000 size:
>> 00000000b7ec0000 end: 00000000b7fc0000 type: 1
>> Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7fc0000 size:
>> 000000000000e000 end: 00000000b7fce000 type: 3
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7fce000 size:
>> 0000000000022000 end: 00000000b7ff0000 type: 4
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000b7ff0000 size:
>> 0000000000010000 end: 00000000b8000000 type: 2
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000fec00000 size:
>> 0000000000001000 end: 00000000fec01000 type: 2
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000fee00000 size:
>> 0000000000100000 end: 00000000fef00000 type: 2
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 00000000ff780000 size:
>> 0000000000880000 end: 0000000100000000 type: 2
>> Jun 3 13:50:52 fawkes copy_e820_map() start: 0000000100000000 size:
>> 0000000040000000 end: 0000000140000000 type: 1
>> Jun 3 13:50:52 fawkes copy_e820_map() type is E820_RAM
>> Jun 3 13:50:52 fawkes BIOS-e820: 0000000000000000 - 000000000009fc00
>> (usable)
>> Jun 3 13:50:52 fawkes BIOS-e820: 000000000009fc00 - 00000000000a0000
>> (reserved)
>> Jun 3 13:50:52 fawkes BIOS-e820: 00000000000e0000 - 0000000000100000
>> (reserved)
>> Jun 3 13:50:52 fawkes BIOS-e820: 0000000000100000 - 00000000b7fc0000
>> (usable)
>> Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7fc0000 - 00000000b7fce000
>> (ACPI data)
>> Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7fce000 - 00000000b7ff0000
>> (ACPI NVS)
>> Jun 3 13:50:52 fawkes BIOS-e820: 00000000b7ff0000 - 00000000b8000000
>> (reserved)
>> Jun 3 13:50:52 fawkes BIOS-e820: 00000000fec00000 - 00000000fec01000
>> (reserved)
>> Jun 3 13:50:52 fawkes BIOS-e820: 00000000fee00000 - 00000000fef00000
>> (reserved)
>> Jun 3 13:50:52 fawkes BIOS-e820: 00000000ff780000 - 0000000100000000
>> (reserved)
>> Jun 3 13:50:52 fawkes BIOS-e820: 0000000100000000 - 0000000140000000
>> (usable)
>> Jun 3 13:50:52 fawkes Warning only 4GB will be used.
>> Jun 3 13:50:52 fawkes Use a PAE enabled kernel.
>>
>
> Oh look, it even tells you right there that you have to use a PAE (>4GB
> for 32bit machines) kernel to get all your ram.
>
> --
> Len Sorensen
>
Tom Moore wrote:
> Thank you for the reply back. Your answer makes perfect sense to me,
> and it is what I had suspected but was not sure about. The math seems
> to indicate that 4Gb of ram plus 1Gb of PCI address space equals 5Gb of
> memory space. So it does sound like I should have a larger kernel model.
>
> What confused me the most (and still does), is the help message string
> that is presented for the CONFIG_HIGHMEM4G option:
> "Select this if you have a 32-bit processor and between 1 and 4
> gigabytes of physical RAM."
4 is not between 1 and 4.
> Well that sounds like the amount of memory that I have, so that is what
> I selected.
You should select CONFIG_HIGHMEM64G.
> Also, although I know what PAE stands for, I don't know how to select it
> when building a kernel. Would I get this from the CONFIG_HIGHMEM64G
> option? The help text for that says:
> "Select this if you have a 32-bit processor and more than 4 gigabytes
> of physical RAM."
Personally, I feel the wording should say:
Select this if you have a 32-bit processor and 4 or more gigabytes of
physical RAM.
It may not hurt to say 3 or more, but I'm not that familiar with x86
hardware in regards to memory.
> This does not sound like it applies to my hardware. There is something
> wrong with my understanding, or with these message strings. I am still
> confused.
It does.
Here's my system (4gb of memory):
total used free shared buffers cached
Mem: 3619996 3289352 330644 0 469764 2025416
-/+ buffers/cache: 794172 2825824
Swap: 0 0 0
I know it says 3.6gb of memory, but 4gb is installed. I had 5gb in this
machine and I saw all 5gb. This is a 32-bit dual xeon (12gb max memory)
I would be interested to know where the last 400mb of memory went.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???
Wakko Warner wrote:
> Tom Moore wrote:
>
>> Thank you for the reply back. Your answer makes perfect sense to me,
>> and it is what I had suspected but was not sure about. The math seems
>> to indicate that 4Gb of ram plus 1Gb of PCI address space equals 5Gb of
>> memory space. So it does sound like I should have a larger kernel model.
>>
>> What confused me the most (and still does), is the help message string
>> that is presented for the CONFIG_HIGHMEM4G option:
>> "Select this if you have a 32-bit processor and between 1 and 4
>> gigabytes of physical RAM."
>>
>
> 4 is not between 1 and 4.
>
This idiomatic phrase suggests to me that it applies when ram is >= 1Gb
and <= 4Gb. The fact that we interpret it differently indicates that it
could be more clearly stated. If your interpretation is correct, then
what would this mean when a machine had 3.5Gb of ram installed?
>
>> Well that sounds like the amount of memory that I have, so that is what
>> I selected.
>>
>
> You should select CONFIG_HIGHMEM64G.
>
>
>> Also, although I know what PAE stands for, I don't know how to select it
>> when building a kernel. Would I get this from the CONFIG_HIGHMEM64G
>> option? The help text for that says:
>> "Select this if you have a 32-bit processor and more than 4 gigabytes
>> of physical RAM."
>>
>
> Personally, I feel the wording should say:
> Select this if you have a 32-bit processor and 4 or more gigabytes of
> physical RAM.
>
> It may not hurt to say 3 or more, but I'm not that familiar with x86
> hardware in regards to memory.
>
>
Ok, so it appears that this one is wrong also. If someone could explain
the rules that apply, I would be happy to prepare a patch to the Kconfig
script. I don't consider myself to be completely stupid, and if the
help text was a bit more clear I wouldn't be asking these questions.
I'm sure that other pilgrims will follow along later with the same
questions.
>> This does not sound like it applies to my hardware. There is something
>> wrong with my understanding, or with these message strings. I am still
>> confused.
>>
>
> It does.
>
> Here's my system (4gb of memory):
> total used free shared buffers cached
> Mem: 3619996 3289352 330644 0 469764 2025416
> -/+ buffers/cache: 794172 2825824
> Swap: 0 0 0
>
> I know it says 3.6gb of memory, but 4gb is installed. I had 5gb in this
> machine and I saw all 5gb. This is a 32-bit dual xeon (12gb max memory)
>
> I would be interested to know where the last 400mb of memory went.
>
>
On Tue, Jun 05, 2007 at 09:12:00AM -0400, Tom Moore wrote:
> Ok, so it appears that this one is wrong also. If someone could explain
> the rules that apply, I would be happy to prepare a patch to the Kconfig
> script. I don't consider myself to be completely stupid, and if the
> help text was a bit more clear I wouldn't be asking these questions.
> I'm sure that other pilgrims will follow along later with the same
> questions.
If you do create such a patch, please also state that HIGHMEM64G is
necessary for support of the NX bit (on those processors that support
it).
ISTR that a similar issue exists in the NOHIGHMEM case, where some
150MB or so of RAM would be unusable in a 1GB machine with NOHIGHMEM.
I could be mis-remembering, that, though.
--
Joseph Fannin
[email protected] || [email protected]
On Mon, Jun 04, 2007 at 03:43:08PM -0400, Tom Moore wrote:
> Thank you for the reply back. Your answer makes perfect sense to me,
> and it is what I had suspected but was not sure about. The math seems
> to indicate that 4Gb of ram plus 1Gb of PCI address space equals 5Gb of
> memory space. So it does sound like I should have a larger kernel model.
>
> What confused me the most (and still does), is the help message string
> that is presented for the CONFIG_HIGHMEM4G option:
> "Select this if you have a 32-bit processor and between 1 and 4
> gigabytes of physical RAM."
A better description would be:
"Select this if you have a 32-bit processor and memory mapped in the 1GB
to 4GB address range."
> Well that sounds like the amount of memory that I have, so that is what
> I selected.
>
> Also, although I know what PAE stands for, I don't know how to select it
> when building a kernel. Would I get this from the CONFIG_HIGHMEM64G
> option? The help text for that says:
> "Select this if you have a 32-bit processor and more than 4 gigabytes
> of physical RAM."
That one would be better as:
"Select this if you have a 32-bit processor and ram mapped in the address
range above 4GB."
> This does not sound like it applies to my hardware. There is something
> wrong with my understanding, or with these message strings. I am still
> confused.
In the past a number of machines couldn't remap memory, so you simply
lost any that was covered by the PCI address space. In that case 4GB
ram mean you got 3GB or 3.5GB ram, and turning on HIGHMEM64G wouldn't
help.
In your case with some ram mapped above 4GB, you want the option that
supports up to 64GB ram (the limit of PAE) which is the
CONFIG_HIGHMEM64G. After all since some ram is mapped between 4 and
5GB, it is as if you had 5GB ram, but the part between 3 and 4GB was
covered up. You are just lucky enough that the covered up part got
moved out of the way instead so you get to use it.
--
Len Sorensen
Tom Moore <[email protected]> writes:
> Hi everyone.
>
> I am having some difficulty trying to get my 4Gb of ram recognized by
This really seems to become a FAQ recently. Please look in the archives.
In short your BIOS is broken. Complain to your BIOS vendor.
Anyone interested to write up some web page (all the necessary
information on this has been posted many times in the past) with
a FAQ that people could be pointed to?
-Andi
On 6/6/07, Lennart Sorensen <[email protected]> wrote:
> [...]
> A better description would be:
>
> "Select this if you have a 32-bit processor and memory mapped in the 1GB
> to 4GB address range."
> [...]
> That one would be better as:
>
> "Select this if you have a 32-bit processor and ram mapped in the address
> range above 4GB."
Ugh, no! How can we expect the user compiling a kernel to be *so*
familiar with address space re-mapping / BIOSen (_his_ particular
BIOS, specifically, and what / how it re-maps memory) / etc to be
able to answer such questions? "Select ... if you have ... RAM
installed" is perfectly clear, simple, and all that's needed.
BTW, just imagine what a user would need to do to make things
work as per your proposal. Build some kernel (don't care about
memory loss), boot and find what his firmware prefers to do with
address space (or else read up the BIOS documentation!) and
_then_ again build a new kernel, this time selecting the options
appropriately ...
Also, note that the change you're proposing is unnecessary! As
Andi pointed out, this issue has more to do with broken BIOSen
and the proper fix for Tom is to contact his vendor and flash /
upgrade the BIOS firmware. I don't see anything wrong with the
Kconfig help texts.
On Jun 7 2007 02:48, Satyam Sharma wrote:
> On 6/6/07, Lennart Sorensen <[email protected]> wrote:
>> [...]
>> A better description would be:
>>
>> "Select this if you have a 32-bit processor and memory mapped in the 1GB
>> to 4GB address range."
>> [...]
>> That one would be better as:
>>
>> "Select this if you have a 32-bit processor and ram mapped in the address
>> range above 4GB."
>
> Ugh, no! How can we expect the user compiling a kernel to be *so*
> familiar with address space re-mapping / BIOSen (_his_ particular
> BIOS, specifically, and what / how it re-maps memory) / etc to be
> able to answer such questions? "Select ... if you have ... RAM
> installed" is perfectly clear, simple, and all that's needed.
Then explain it.
"Select this if you have a 32 bit cpu and ram mapped above 4 G.
To see where RAM is mapped, interpret the E820 lines from dmesg,
for more information see Documentation/e820.txt"
or something like that.
Jan
--
Satyam Sharma wrote:
> On 6/6/07, Lennart Sorensen <[email protected]> wrote:
>> [...]
>> A better description would be:
>>
>> "Select this if you have a 32-bit processor and memory mapped in the 1GB
>> to 4GB address range."
>> [...]
>> That one would be better as:
>>
>> "Select this if you have a 32-bit processor and ram mapped in the
>> address
>> range above 4GB."
>
> Ugh, no! How can we expect the user compiling a kernel to be *so*
> familiar with address space re-mapping / BIOSen (_his_ particular
> BIOS, specifically, and what / how it re-maps memory) / etc to be
> able to answer such questions? "Select ... if you have ... RAM
> installed" is perfectly clear, simple, and all that's needed.
>
However the KConfig help message as it is currently written is wrong.
> BTW, just imagine what a user would need to do to make things
> work as per your proposal. Build some kernel (don't care about
> memory loss), boot and find what his firmware prefers to do with
> address space (or else read up the BIOS documentation!) and
> _then_ again build a new kernel, this time selecting the options
> appropriately ...
I tried to do this, but the Kconfig help message was misleading. I
still needed to come here for help.
>
> Also, note that the change you're proposing is unnecessary! As
> Andi pointed out, this issue has more to do with broken BIOSen
> and the proper fix for Tom is to contact his vendor and flash /
> upgrade the BIOS firmware. I don't see anything wrong with the
> Kconfig help texts.
Andi was wrong. It appears that he read the first sentence of my email
and jumped to a conclusion. The /proc/mtrr output that I included in my
first post showed the my bios was doing the right thing. My problem was
that I was using CONFIG_HIGHMEM4G, which is what the KConfig help
message told me to do. After switching to CONFIG_HIGHMEM64G the OS was
able to map all of my ram.
total used free shared buffers cached
Mem: 4016768 3924312 92456 0 360132 3030336
-/+ buffers/cache: 533844 3482924
Swap: 5116692 2676 5114016
Thanks to those with the correct advice. I'm sure I would have got this
by trying each memory model in turn, but at least now I know what is
going on.
Tom
On Thu, Jun 07, 2007 at 02:48:50AM +0530, Satyam Sharma wrote:
> Ugh, no! How can we expect the user compiling a kernel to be *so*
> familiar with address space re-mapping / BIOSen (_his_ particular
> BIOS, specifically, and what / how it re-maps memory) / etc to be
> able to answer such questions? "Select ... if you have ... RAM
> installed" is perfectly clear, simple, and all that's needed.
>
> BTW, just imagine what a user would need to do to make things
> work as per your proposal. Build some kernel (don't care about
> memory loss), boot and find what his firmware prefers to do with
> address space (or else read up the BIOS documentation!) and
> _then_ again build a new kernel, this time selecting the options
> appropriately ...
>
> Also, note that the change you're proposing is unnecessary! As
> Andi pointed out, this issue has more to do with broken BIOSen
> and the proper fix for Tom is to contact his vendor and flash /
> upgrade the BIOS firmware. I don't see anything wrong with the
> Kconfig help texts.
Well no. If you have 4GB of ram, and a proper BIOS, then you NEED a
kernel configured for 64GB ram since PCI will take at least 0.5GB of it
and make it remapped above the 4GB address. So describing the
CONFIG_4GB option as being correct for people with 1 to 4GB ram is very
much wrong for almost all systems. It would only be correct for those
systems where the bios or chipset incorrectly does not remap memory
above the PCI address space. The current description is in fact wrong
when the bios isn't broken. Somewhere around 3 or 3.5GB seems to be the
limit for the CONFIG_4GB option. Any more and you need the CONFIG_64GB
option instead, unless your bios and/or chipset sucks in which case you
simply loose the ram in the PCI space and you might as well stick with
the CONFIG_4GB option to keep full performance.
--
Len Sorensen