System Ram Not Completely Recognized

Steve Alligood steve at
Fri Jun 28 10:13:01 MDT 2013

On Jun 28, 2013, at 12:44 AM, Levi Pearson wrote:

> On Thu, Jun 27, 2013 at 5:53 PM, Nathan England <nathan at> wrote:
>> On Thursday, June 27, 2013 05:39:25 PM Chris wrote:
>>> dmidecode might provide some details to ponder.
>> I was just in the middle of reading dmidecode when you sent this. And it
>> occurred to me, this stupid motherboard should not even allow "unganged" mode
>> when the present IGP is in use. Duh!
>> Anyway, I have the BIOs set to use 64MB but I found a section in dmidecode
>> which says:
>> Handle 0x0012, DMI type 20, 35 bytes
>> Memory Device Mapped Address
>>        Starting Address: 0x00180000000
>>        Ending Address: 0x001FFFFFFF
>>        Range Size: 2 GB
>>        Physical Device Handle: 0x000B
>> That 0x000B is one of the memory chips; DIMM1 BANK1.
>> So that DIMM is not being used. But the BIOS recognizes it!!! So what gives?
> Anyway, I just looked a bit into the x86 boot code in the Linux source
> tree, and indeed the kernel makes an e820 call to the BIOS to get the
> memory map.  It looks like you might be able to supply your own e820
> map via the kernel command line as well.  You should also be able to
> see the map it gets from the BIOS from your dmesg data.  If you could
> reproduce the live-cd boot in which you got it to see all 8G, you
> might be able to use the dmesg map there to program grub to supply it
> via the kernel command line.

or just juggle the ram to a different slot and see if the issue moves as well.

If it moves, just replace the dimm (cheaper than the time to do all the above).  If it does not move, the slot may have issues.


More information about the PLUG mailing list