[lkml]   [2007]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectIntel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?

    Dear Customer,

    Thank you for contacting Intel(R) Technical Support.

    After reviewing the email history on this case, we have the following suggestions/comments:

    Note before continuing: Debian* Linux Operating System is not an officially, validated, tested Operating System for the Intel(R) Desktop Board DG965WH (see; moreover, we do confirm that "on a system that has 8 GB of system memory installed, it is not possible to use all of the installed memory due to system address space being allocated for other system critical functions." [qtd. on page 43 of the Technical Product Specification (see]. Thus, the following suggestions are provided AS IS; we cannot guarantee the problem would be fixed afterwards:

    1. Try updating the BIOS to the most current version (1687):

    Note: Once the update is done, please, restart the system and repeat the following:

    Press <F9> to restore BIOS default settings. Reset any customized BIOS settings. Clear all DMI event logs, which are located in the Advanced/Event Log Configuration section of the BIOS Setup utility. Press <F10> to save the new settings and reboot the system.

    2. If the problem continues, please, ensure the brand and part# of the memory modules are listed among the tested memory lists (see


    Before I upgraded to 8GB, I used to upgrade my BIOS everytime a new
    version came out, however, once I upgraded past 1666P I also noticed this
    problem even with 4GB of memory, I tried to downgrade back to 1666P and it
    corrupted the BIOS/failed and I had to wait 1-2 weeks for the RMA process,
    1 week to get there, 1-3 days for analysis etc, they do ship two-day
    shipping back to you however..

    Per Robert's response, this is the fix I will be using as Intel wants me
    to upgrade the BIOS to the defaults, which could potentially cause another
    motherboard failure. I'll stick with the mem= option. I need to read up
    on the E820 memory map.

    How come the kernel does not automatically map the memory correctly and
    then put a message in syslog/dmesg: Only using 7.7GB because your BIOS is
    using 64MB for other purposes, re-mapping kernel into higher memory..

    Any comments?

    Per Robert below:

    Justin Piszcz wrote:
    > That output looked nasty, attaching entries from syslog.
    > Justin.

    Here's your E820 memory map, from dmesg:

    BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
    BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
    BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
    BIOS-e820: 0000000000100000 - 00000000cf58f000 (usable)
    BIOS-e820: 00000000cf58f000 - 00000000cf59c000 (reserved)
    BIOS-e820: 00000000cf59c000 - 00000000cf653000 (usable)
    BIOS-e820: 00000000cf653000 - 00000000cf6a5000 (ACPI NVS)
    BIOS-e820: 00000000cf6a5000 - 00000000cf6a8000 (ACPI data)
    BIOS-e820: 00000000cf6a8000 - 00000000cf6ef000 (ACPI NVS)
    BIOS-e820: 00000000cf6ef000 - 00000000cf6f1000 (ACPI data)
    BIOS-e820: 00000000cf6f1000 - 00000000cf6f2000 (usable)
    BIOS-e820: 00000000cf6f2000 - 00000000cf6ff000 (ACPI data)
    BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
    BIOS-e820: 00000000cf700000 - 00000000d0000000 (reserved)
    BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
    BIOS-e820: 0000000100000000 - 000000022c000000 (usable)

    so the usable memory ranges are:


    and the MTRRs (from /proc/mtrr, from private email):

    reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
    reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
    reg03: base=0xcf800000 (3320MB), size= 8MB: uncachable, count=1
    reg04: base=0xcf700000 (3319MB), size= 1MB: uncachable, count=1
    reg05: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
    reg06: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
    reg07: base=0x220000000 (8704MB), size= 128MB: write-back, count=1

    so the ranges mapped as cacheable are:


    leaving 64MB of memory at the top of RAM uncached. What do you want to
    bet that something important (kernel code?) is getting loaded there..

    So essentially it's a BIOS problem, it's not setting up the MTRRs
    properly in order to map all of RAM as cacheable. As Andi says, complain
    to Intel.

    Robert Hancock Saskatoon, SK, Canada
    To email, remove "nospam" from
    Home Page:

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-01 20:17    [W:0.045 / U:8.908 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site