[PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M - Kernel

This is a discussion on [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M - Kernel ; make the print out right with size Signed-off-by: Yinghai Lu --- arch/x86/kernel/cpu/mtrr/main.c | 109 ++++++++++++++++++++++++++++++---------- 1 file changed, 82 insertions(+), 27 deletions(-) Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c ================================================== ================= --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -905,6 +905,27 @@ set_var_mtrr_all(unsigned int address_bi } } +static ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 28

Thread: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

  1. [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

    make the print out right with size < 1M

    Signed-off-by: Yinghai Lu

    ---
    arch/x86/kernel/cpu/mtrr/main.c | 109 ++++++++++++++++++++++++++++++----------
    1 file changed, 82 insertions(+), 27 deletions(-)

    Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
    ================================================== =================
    --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c
    +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
    @@ -905,6 +905,27 @@ set_var_mtrr_all(unsigned int address_bi
    }
    }

    +static unsigned long to_size_factor(unsigned long sizek, char *factorp)
    +{
    + char factor;
    + unsigned long base = sizek;
    +
    + if (base & ((1<<10) - 1)) {
    + /* not MB alignment */
    + factor = 'K';
    + } else if (base & ((1<<20) - 1)){
    + factor = 'M';
    + base >>= 10;
    + } else {
    + factor = 'G';
    + base >>= 20;
    + }
    +
    + *factorp = factor;
    +
    + return base;
    +}
    +
    static unsigned int __init
    range_to_mtrr(unsigned int reg, unsigned long range_startk,
    unsigned long range_sizek, unsigned char type)
    @@ -926,13 +947,21 @@ range_to_mtrr(unsigned int reg, unsigned
    align = max_align;

    sizek = 1 << align;
    - if (debug_print)
    + if (debug_print) {
    + char start_factor = 'K', size_factor = 'K';
    + unsigned long start_base, size_base;
    +
    + start_base = to_size_factor(range_startk, &start_factor),
    + size_base = to_size_factor(sizek, &size_factor),
    +
    printk(KERN_DEBUG "Setting variable MTRR %d, "
    - "base: %ldMB, range: %ldMB, type %s\n",
    - reg, range_startk >> 10, sizek >> 10,
    + "base: %ld%cB, range: %ld%cB, type %s\n",
    + reg, start_base, start_factor,
    + size_base, size_factor,
    (type == MTRR_TYPE_UNCACHABLE)?"UC":
    ((type == MTRR_TYPE_WRBACK)?"WB":"Other")
    );
    + }
    save_var_mtrr(reg++, range_startk, sizek, type);
    range_startk += sizek;
    range_sizek -= sizek;
    @@ -1244,6 +1273,8 @@ static int __init mtrr_cleanup(unsigned

    if (mtrr_chunk_size && mtrr_gran_size) {
    int num_reg;
    + char gran_factor, chunk_factor, lose_factor;
    + unsigned long gran_base, chunk_base, lose_base;

    debug_print++;
    /* convert ranges to var ranges state */
    @@ -1269,12 +1300,15 @@ static int __init mtrr_cleanup(unsigned
    result[i].lose_cover_sizek =
    (range_sums - range_sums_new) << PSHIFT;

    - printk(KERN_INFO "%sgran_size: %ldM \tchunk_size: %ldM \t",
    - result[i].bad?"*BAD*":" ", result[i].gran_sizek >> 10,
    - result[i].chunk_sizek >> 10);
    - printk(KERN_CONT "num_reg: %d \tlose cover RAM: %s%ldM \n",
    + gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
    + chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
    + lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
    + printk(KERN_INFO "%sgran_size: %ld%c \tchunk_size: %ld%c \t",
    + result[i].bad?"*BAD*":" ",
    + gran_base, gran_factor, chunk_base, chunk_factor);
    + printk(KERN_CONT "num_reg: %d \tlose cover RAM: %s%ld%c\n",
    result[i].num_reg, result[i].bad?"-":"",
    - result[i].lose_cover_sizek >> 10);
    + lose_base, lose_factor);
    if (!result[i].bad) {
    set_var_mtrr_all(address_bits);
    return 1;
    @@ -1289,14 +1323,25 @@ static int __init mtrr_cleanup(unsigned
    memset(min_loss_pfn, 0xff, sizeof(min_loss_pfn));
    memset(result, 0, sizeof(result));
    for (gran_size = (1ULL<<20); gran_size < (1ULL<<32); gran_size <<= 1) {
    + char gran_factor;
    + unsigned long gran_base;
    +
    + if (debug_print)
    + gran_base = to_size_factor(gran_size >> 10, &gran_factor);
    +
    for (chunk_size = gran_size; chunk_size < (1ULL<<32);
    chunk_size <<= 1) {
    int num_reg;

    - if (debug_print)
    - printk(KERN_INFO
    - "\ngran_size: %lldM chunk_size_size: %lldM\n",
    - gran_size >> 20, chunk_size >> 20);
    + if (debug_print) {
    + char chunk_factor;
    + unsigned long chunk_base;
    +
    + chunk_base = to_size_factor(chunk_size>>10, &chunk_factor),
    + printk(KERN_INFO "\n");
    + printk(KERN_INFO "gran_size: %ld%c chunk_size: %ld%c \n",
    + gran_base, gran_factor, chunk_base, chunk_factor);
    + }
    if (i >= NUM_RESULT)
    continue;

    @@ -1339,12 +1384,18 @@ static int __init mtrr_cleanup(unsigned

    /* print out all */
    for (i = 0; i < NUM_RESULT; i++) {
    - printk(KERN_INFO "%sgran_size: %ldM \tchunk_size: %ldM \t",
    - result[i].bad?"*BAD* ":" ", result[i].gran_sizek >> 10,
    - result[i].chunk_sizek >> 10);
    - printk(KERN_CONT "num_reg: %d \tlose RAM: %s%ldM\n",
    - result[i].num_reg, result[i].bad?"-":"",
    - result[i].lose_cover_sizek >> 10);
    + char gran_factor, chunk_factor, lose_factor;
    + unsigned long gran_base, chunk_base, lose_base;
    +
    + gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
    + chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
    + lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
    + printk(KERN_INFO "%sgran_size: %ld%c \tchunk_size: %ld%c \t",
    + result[i].bad?"*BAD*":" ",
    + gran_base, gran_factor, chunk_base, chunk_factor);
    + printk(KERN_CONT "num_reg: %d \tlose cover RAM: %s%ld%c\n",
    + result[i].num_reg, result[i].bad?"-":"",
    + lose_base, lose_factor);
    }

    /* try to find the optimal index */
    @@ -1369,14 +1420,18 @@ static int __init mtrr_cleanup(unsigned
    }

    if (index_good != -1) {
    + char gran_factor, chunk_factor, lose_factor;
    + unsigned long gran_base, chunk_base, lose_base;
    +
    printk(KERN_INFO "Found optimal setting for mtrr clean up\n");
    i = index_good;
    - printk(KERN_INFO "gran_size: %ldM \tchunk_size: %ldM \t",
    - result[i].gran_sizek >> 10,
    - result[i].chunk_sizek >> 10);
    - printk(KERN_CONT "num_reg: %d \tlose RAM: %ldM\n",
    - result[i].num_reg,
    - result[i].lose_cover_sizek >> 10);
    + gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
    + chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
    + lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
    + printk(KERN_INFO "gran_size: %ld%c \tchunk_size: %ld%c \t",
    + gran_base, gran_factor, chunk_base, chunk_factor);
    + printk(KERN_CONT "num_reg: %d \tlose RAM: %ld%c\n",
    + result[i].num_reg, lose_base, lose_factor);
    /* convert ranges to var ranges state */
    chunk_size = result[i].chunk_sizek;
    chunk_size <<= 10;
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

    Applied series to tip:x86/mtrr, thanks!

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M


    * H. Peter Anvin wrote:

    > Applied series to tip:x86/mtrr, thanks!


    tested them and pushed it out into tip/master.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M


    * Ingo Molnar wrote:

    > * H. Peter Anvin wrote:
    >
    > > Applied series to tip:x86/mtrr, thanks!

    >
    > tested them and pushed it out into tip/master.


    btw., now that we've got wide enough exposure (a kernel release), could
    we please flip around the default of CONFIG_MTRR_SANITIZER and make it
    default-y? This feature should only produce a worse result if there's a
    bug in that code, right?

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

    On Tue, Sep 30, 2008 at 1:11 AM, Ingo Molnar wrote:
    >
    > * Ingo Molnar wrote:
    >
    >> * H. Peter Anvin wrote:
    >>
    >> > Applied series to tip:x86/mtrr, thanks!

    >>
    >> tested them and pushed it out into tip/master.

    >
    > btw., now that we've got wide enough exposure (a kernel release), could
    > we please flip around the default of CONFIG_MTRR_SANITIZER and make it
    > default-y? This feature should only produce a worse result if there's a
    > bug in that code, right?


    it will compare the exact mem range between the updated and original,
    so it should be safe to set it to default-y.

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

    Ingo Molnar wrote:
    > * Ingo Molnar wrote:
    >
    >> * H. Peter Anvin wrote:
    >>
    >>> Applied series to tip:x86/mtrr, thanks!

    >> tested them and pushed it out into tip/master.

    >
    > btw., now that we've got wide enough exposure (a kernel release), could
    > we please flip around the default of CONFIG_MTRR_SANITIZER and make it
    > default-y? This feature should only produce a worse result if there's a
    > bug in that code, right?
    >


    Yes. Furthermore, right now the code has to be enabled *and* a kernel
    command line option has to be passed. I suspect we eventually want to
    runtime-enable it by default, too.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:

    > one have gran < 1M
    >
    > reg00: base=0xd8000000 (3456MB), size= 128MB: uncachable, count=1
    > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
    > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
    > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
    > reg05: base=0xd7f80000 (3455MB), size= 512KB: uncachable, count=1
    >
    > will get
    >
    > Found optimal setting for mtrr clean up
    > gran_size: 512K chunk_size: 2M num_reg: 7 lose RAM: 0G
    > range0: 0000000000000000 - 00000000d8000000
    > Setting variable MTRR 0, base: 0GB, range: 2GB, type WB
    > Setting variable MTRR 1, base: 2GB, range: 1GB, type WB
    > Setting variable MTRR 2, base: 3GB, range: 256MB, type WB
    > Setting variable MTRR 3, base: 3328MB, range: 128MB, type WB
    > hole: 00000000d7f00000 - 00000000d7f80000
    > Setting variable MTRR 4, base: 3455MB, range: 512KB, type UC
    > rangeX: 0000000100000000 - 0000000128000000
    > Setting variable MTRR 5, base: 4GB, range: 512MB, type WB
    > Setting variable MTRR 6, base: 4608MB, range: 128MB, type WB
    >
    > so start from 64k instead of 1M
    >


    Or there is something I don't catch about mtrrs, or it still does silly
    things.

    I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:

    werewolf:/proc> cat mtrr
    reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
    reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
    reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
    reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
    reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1
    reg05: base=0x7c000000 (1984MB), size= 64MB: write-back, count=1
    reg06: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1

    So it adds a last WB zone, but substracts the last 1Mb. (Why do
    I have that stupid uncacheable mb ? probably a bios issue...)
    But those two 64 mb zones could be add to a 128Mb, that new one
    with previous to 256Mb and so on, giving something like:

    reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    reg01: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1

    Is this incorrect ?

    dmesg is below

    Linux version 2.6.26-jam14 (root@werewolf.home) (gcc version 4.3.2 (GCC) ) #2 SMP PREEMPT Thu Oct 2 23:48:10 CEST 2008
    BIOS-provided physical RAM map:
    BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
    BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
    BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
    BIOS-e820: 0000000000100000 - 000000007fee0000 (usable)
    BIOS-e820: 000000007fee0000 - 000000007fee3000 (ACPI NVS)
    BIOS-e820: 000000007fee3000 - 000000007fef0000 (ACPI data)
    BIOS-e820: 000000007fef0000 - 000000007ff00000 (reserved)
    BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
    last_pfn = 0x7fee0 max_arch_pfn = 0x100000
    x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
    total RAM coverred: 2047M
    gran_size: 64K chunk_size: 64K num_reg: 8 lose cover RAM: 7M
    gran_size: 64K chunk_size: 128K num_reg: 8 lose cover RAM: 7M
    gran_size: 64K chunk_size: 256K num_reg: 8 lose cover RAM: 7M
    gran_size: 64K chunk_size: 512K num_reg: 8 lose cover RAM: 7M
    gran_size: 64K chunk_size: 1M num_reg: 8 lose cover RAM: 7M
    gran_size: 64K chunk_size: 2M num_reg: 8 lose cover RAM: 7M
    gran_size: 64K chunk_size: 4M num_reg: 8 lose cover RAM: 7M
    gran_size: 64K chunk_size: 8M num_reg: 8 lose cover RAM: 7M
    *BAD*gran_size: 64K chunk_size: 16M num_reg: 8 lose cover RAM: -1M
    gran_size: 64K chunk_size: 32M num_reg: 8 lose cover RAM: 0G
    gran_size: 64K chunk_size: 64M num_reg: 7 lose cover RAM: 0G
    gran_size: 64K chunk_size: 128M num_reg: 6 lose cover RAM: 0G
    gran_size: 64K chunk_size: 256M num_reg: 5 lose cover RAM: 0G
    gran_size: 64K chunk_size: 512M num_reg: 4 lose cover RAM: 0G
    gran_size: 64K chunk_size: 1G num_reg: 3 lose cover RAM: 0G
    gran_size: 64K chunk_size: 2G num_reg: 2 lose cover RAM: 0G
    gran_size: 64K chunk_size: 4G num_reg: 8 lose cover RAM: 7M
    gran_size: 128K chunk_size: 128K num_reg: 8 lose cover RAM: 7M
    gran_size: 128K chunk_size: 256K num_reg: 8 lose cover RAM: 7M
    gran_size: 128K chunk_size: 512K num_reg: 8 lose cover RAM: 7M
    gran_size: 128K chunk_size: 1M num_reg: 8 lose cover RAM: 7M
    gran_size: 128K chunk_size: 2M num_reg: 8 lose cover RAM: 7M
    gran_size: 128K chunk_size: 4M num_reg: 8 lose cover RAM: 7M
    gran_size: 128K chunk_size: 8M num_reg: 8 lose cover RAM: 7M
    *BAD*gran_size: 128K chunk_size: 16M num_reg: 8 lose cover RAM: -1M
    gran_size: 128K chunk_size: 32M num_reg: 8 lose cover RAM: 0G
    gran_size: 128K chunk_size: 64M num_reg: 7 lose cover RAM: 0G
    gran_size: 128K chunk_size: 128M num_reg: 6 lose cover RAM: 0G
    gran_size: 128K chunk_size: 256M num_reg: 5 lose cover RAM: 0G
    gran_size: 128K chunk_size: 512M num_reg: 4 lose cover RAM: 0G
    gran_size: 128K chunk_size: 1G num_reg: 3 lose cover RAM: 0G
    gran_size: 128K chunk_size: 2G num_reg: 2 lose cover RAM: 0G
    gran_size: 128K chunk_size: 4G num_reg: 8 lose cover RAM: 7M
    gran_size: 256K chunk_size: 256K num_reg: 8 lose cover RAM: 7M
    gran_size: 256K chunk_size: 512K num_reg: 8 lose cover RAM: 7M
    gran_size: 256K chunk_size: 1M num_reg: 8 lose cover RAM: 7M
    gran_size: 256K chunk_size: 2M num_reg: 8 lose cover RAM: 7M
    gran_size: 256K chunk_size: 4M num_reg: 8 lose cover RAM: 7M
    gran_size: 256K chunk_size: 8M num_reg: 8 lose cover RAM: 7M
    *BAD*gran_size: 256K chunk_size: 16M num_reg: 8 lose cover RAM: -1M
    gran_size: 256K chunk_size: 32M num_reg: 8 lose cover RAM: 0G
    gran_size: 256K chunk_size: 64M num_reg: 7 lose cover RAM: 0G
    gran_size: 256K chunk_size: 128M num_reg: 6 lose cover RAM: 0G
    gran_size: 256K chunk_size: 256M num_reg: 5 lose cover RAM: 0G
    gran_size: 256K chunk_size: 512M num_reg: 4 lose cover RAM: 0G
    gran_size: 256K chunk_size: 1G num_reg: 3 lose cover RAM: 0G
    gran_size: 256K chunk_size: 2G num_reg: 2 lose cover RAM: 0G
    gran_size: 256K chunk_size: 4G num_reg: 8 lose cover RAM: 7M
    gran_size: 512K chunk_size: 512K num_reg: 8 lose cover RAM: 7M
    gran_size: 512K chunk_size: 1M num_reg: 8 lose cover RAM: 7M
    gran_size: 512K chunk_size: 2M num_reg: 8 lose cover RAM: 7M
    gran_size: 512K chunk_size: 4M num_reg: 8 lose cover RAM: 7M
    gran_size: 512K chunk_size: 8M num_reg: 8 lose cover RAM: 7M
    *BAD*gran_size: 512K chunk_size: 16M num_reg: 8 lose cover RAM: -1M
    gran_size: 512K chunk_size: 32M num_reg: 8 lose cover RAM: 0G
    gran_size: 512K chunk_size: 64M num_reg: 7 lose cover RAM: 0G
    gran_size: 512K chunk_size: 128M num_reg: 6 lose cover RAM: 0G
    gran_size: 512K chunk_size: 256M num_reg: 5 lose cover RAM: 0G
    gran_size: 512K chunk_size: 512M num_reg: 4 lose cover RAM: 0G
    gran_size: 512K chunk_size: 1G num_reg: 3 lose cover RAM: 0G
    gran_size: 512K chunk_size: 2G num_reg: 2 lose cover RAM: 0G
    gran_size: 512K chunk_size: 4G num_reg: 8 lose cover RAM: 7M
    gran_size: 1M chunk_size: 1M num_reg: 8 lose cover RAM: 7M
    gran_size: 1M chunk_size: 2M num_reg: 8 lose cover RAM: 7M
    gran_size: 1M chunk_size: 4M num_reg: 8 lose cover RAM: 7M
    gran_size: 1M chunk_size: 8M num_reg: 8 lose cover RAM: 7M
    *BAD*gran_size: 1M chunk_size: 16M num_reg: 8 lose cover RAM: -1M
    gran_size: 1M chunk_size: 32M num_reg: 8 lose cover RAM: 0G
    gran_size: 1M chunk_size: 64M num_reg: 7 lose cover RAM: 0G
    gran_size: 1M chunk_size: 128M num_reg: 6 lose cover RAM: 0G
    gran_size: 1M chunk_size: 256M num_reg: 5 lose cover RAM: 0G
    gran_size: 1M chunk_size: 512M num_reg: 4 lose cover RAM: 0G
    gran_size: 1M chunk_size: 1G num_reg: 3 lose cover RAM: 0G
    gran_size: 1M chunk_size: 2G num_reg: 2 lose cover RAM: 0G
    gran_size: 1M chunk_size: 4G num_reg: 8 lose cover RAM: 7M
    gran_size: 2M chunk_size: 2M num_reg: 8 lose cover RAM: 7M
    gran_size: 2M chunk_size: 4M num_reg: 8 lose cover RAM: 7M
    gran_size: 2M chunk_size: 8M num_reg: 8 lose cover RAM: 7M
    *BAD*gran_size: 2M chunk_size: 16M num_reg: 8 lose cover RAM: -1M
    gran_size: 2M chunk_size: 32M num_reg: 8 lose cover RAM: 1M
    gran_size: 2M chunk_size: 64M num_reg: 7 lose cover RAM: 1M
    gran_size: 2M chunk_size: 128M num_reg: 6 lose cover RAM: 1M
    gran_size: 2M chunk_size: 256M num_reg: 5 lose cover RAM: 1M
    gran_size: 2M chunk_size: 512M num_reg: 4 lose cover RAM: 1M
    gran_size: 2M chunk_size: 1G num_reg: 3 lose cover RAM: 1M
    gran_size: 2M chunk_size: 2G num_reg: 2 lose cover RAM: 1M
    gran_size: 2M chunk_size: 4G num_reg: 8 lose cover RAM: 7M
    gran_size: 4M chunk_size: 4M num_reg: 8 lose cover RAM: 7M
    gran_size: 4M chunk_size: 8M num_reg: 8 lose cover RAM: 7M
    *BAD*gran_size: 4M chunk_size: 16M num_reg: 8 lose cover RAM: -1M
    gran_size: 4M chunk_size: 32M num_reg: 8 lose cover RAM: 3M
    gran_size: 4M chunk_size: 64M num_reg: 7 lose cover RAM: 3M
    gran_size: 4M chunk_size: 128M num_reg: 6 lose cover RAM: 3M
    gran_size: 4M chunk_size: 256M num_reg: 5 lose cover RAM: 3M
    gran_size: 4M chunk_size: 512M num_reg: 4 lose cover RAM: 3M
    gran_size: 4M chunk_size: 1G num_reg: 3 lose cover RAM: 3M
    gran_size: 4M chunk_size: 2G num_reg: 2 lose cover RAM: 3M
    gran_size: 4M chunk_size: 4G num_reg: 8 lose cover RAM: 7M
    gran_size: 8M chunk_size: 8M num_reg: 8 lose cover RAM: 7M
    gran_size: 8M chunk_size: 16M num_reg: 8 lose cover RAM: 7M
    gran_size: 8M chunk_size: 32M num_reg: 8 lose cover RAM: 7M
    gran_size: 8M chunk_size: 64M num_reg: 7 lose cover RAM: 7M
    gran_size: 8M chunk_size: 128M num_reg: 6 lose cover RAM: 7M
    gran_size: 8M chunk_size: 256M num_reg: 5 lose cover RAM: 7M
    gran_size: 8M chunk_size: 512M num_reg: 4 lose cover RAM: 7M
    gran_size: 8M chunk_size: 1G num_reg: 3 lose cover RAM: 7M
    gran_size: 8M chunk_size: 2G num_reg: 2 lose cover RAM: 7M
    gran_size: 8M chunk_size: 4G num_reg: 8 lose cover RAM: 7M
    gran_size: 16M chunk_size: 16M num_reg: 7 lose cover RAM: 15M
    gran_size: 16M chunk_size: 32M num_reg: 7 lose cover RAM: 15M
    gran_size: 16M chunk_size: 64M num_reg: 7 lose cover RAM: 15M
    gran_size: 16M chunk_size: 128M num_reg: 6 lose cover RAM: 15M
    gran_size: 16M chunk_size: 256M num_reg: 5 lose cover RAM: 15M
    gran_size: 16M chunk_size: 512M num_reg: 4 lose cover RAM: 15M
    gran_size: 16M chunk_size: 1G num_reg: 3 lose cover RAM: 15M
    gran_size: 16M chunk_size: 2G num_reg: 2 lose cover RAM: 15M
    gran_size: 16M chunk_size: 4G num_reg: 7 lose cover RAM: 15M
    gran_size: 32M chunk_size: 32M num_reg: 6 lose cover RAM: 31M
    gran_size: 32M chunk_size: 64M num_reg: 6 lose cover RAM: 31M
    gran_size: 32M chunk_size: 128M num_reg: 6 lose cover RAM: 31M
    gran_size: 32M chunk_size: 256M num_reg: 5 lose cover RAM: 31M
    gran_size: 32M chunk_size: 512M num_reg: 4 lose cover RAM: 31M
    gran_size: 32M chunk_size: 1G num_reg: 3 lose cover RAM: 31M
    gran_size: 32M chunk_size: 2G num_reg: 2 lose cover RAM: 31M
    gran_size: 32M chunk_size: 4G num_reg: 6 lose cover RAM: 31M
    gran_size: 64M chunk_size: 64M num_reg: 5 lose cover RAM: 63M
    gran_size: 64M chunk_size: 128M num_reg: 5 lose cover RAM: 63M
    gran_size: 64M chunk_size: 256M num_reg: 5 lose cover RAM: 63M
    gran_size: 64M chunk_size: 512M num_reg: 4 lose cover RAM: 63M
    gran_size: 64M chunk_size: 1G num_reg: 3 lose cover RAM: 63M
    gran_size: 64M chunk_size: 2G num_reg: 2 lose cover RAM: 63M
    gran_size: 64M chunk_size: 4G num_reg: 5 lose cover RAM: 63M
    gran_size: 128M chunk_size: 128M num_reg: 4 lose cover RAM: 127M
    gran_size: 128M chunk_size: 256M num_reg: 4 lose cover RAM: 127M
    gran_size: 128M chunk_size: 512M num_reg: 4 lose cover RAM: 127M
    gran_size: 128M chunk_size: 1G num_reg: 3 lose cover RAM: 127M
    Found optimal setting for mtrr clean up
    gran_size: 64K chunk_size: 64M num_reg: 7 lose RAM: 0G
    range0: 0000000000000000 - 000000007c000000
    Setting variable MTRR 0, base: 0GB, range: 1GB, type WB
    Setting variable MTRR 1, base: 1GB, range: 512MB, type WB
    Setting variable MTRR 2, base: 1536MB, range: 256MB, type WB
    Setting variable MTRR 3, base: 1792MB, range: 128MB, type WB
    Setting variable MTRR 4, base: 1920MB, range: 64MB, type WB
    range: 000000007c000000 - 0000000080000000
    Setting variable MTRR 5, base: 1984MB, range: 64MB, type WB
    hole: 000000007ff00000 - 0000000080000000
    Setting variable MTRR 6, base: 2047MB, range: 1MB, type UC
    x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
    After WB checking
    MTRR MAP PFN: 0000000000000000 - 0000000000080000
    After UC checking
    MTRR MAP PFN: 0000000000000000 - 000000000007ff00
    After sorting
    MTRR MAP PFN: 0000000000000000 - 000000000007ff00
    kernel direct mapping tables up to 38000000 @ 7000-c000
    DMI 2.3 present.
    ACPI: RSDP 000F7260, 0014 (r0 IntelR)
    ACPI: RSDT 7FEE3000, 0030 (r1 IntelR AWRDACPI 42302E31 AWRD 0)
    ACPI: FACP 7FEE3040, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD 0)
    ACPI: DSDT 7FEE30C0, 44C1 (r1 INTELR AWRDACPI 1000 MSFT 100000E)
    ACPI: FACS 7FEE0000, 0040
    ACPI: ASF! 7FEE7680, 008A (r32 IntelR AWRDACPI 42302E31 AWRD 0)
    ACPI: APIC 7FEE75C0, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD 0)
    1150MB HIGHMEM available.
    896MB LOWMEM available.
    mapped low ram: 0 - 38000000
    low ram: 00000000 - 38000000
    bootmap 00008000 - 0000f000
    (8 early reservations) ==> bootmem [0000000000 - 0038000000]
    #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
    #1 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000]
    #2 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000]
    #3 [0000100000 - 00004b0ea0] TEXT DATA BSS ==> [0000100000 - 00004b0ea0]
    #4 [00004b1000 - 00004b4000] INIT_PG_TABLE ==> [00004b1000 - 00004b4000]
    #5 [000009f400 - 0000100000] BIOS reserved ==> [000009f400 - 0000100000]
    #6 [0000007000 - 0000008000] PGTABLE ==> [0000007000 - 0000008000]
    #7 [0000008000 - 000000f000] BOOTMAP ==> [0000008000 - 000000f000]
    found SMP MP-table at [c00f57c0] 000f57c0
    Zone PFN ranges:
    DMA 0x00000000 -> 0x00001000
    Normal 0x00001000 -> 0x00038000
    HighMem 0x00038000 -> 0x0007fee0
    Movable zone start PFN for each node
    early_node_map[2] active PFN ranges
    0: 0x00000000 -> 0x0000009f
    0: 0x00000100 -> 0x0007fee0
    On node 0 totalpages: 523903
    free_area_init_node: node 0, pgdat c041a680, node_mem_map c1000000
    DMA zone: 3967 pages, LIFO batch:0
    Normal zone: 223520 pages, LIFO batch:31
    HighMem zone: 292322 pages, LIFO batch:31
    ACPI: PM-Timer IO Port: 0x408
    ACPI: Local APIC address 0xfee00000
    ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
    ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
    ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
    ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
    ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
    ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
    ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
    ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
    ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
    IOAPIC[0]: apic_id 4, 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.
    Enabling APIC mode: Flat. Using 1 I/O APICs
    Using ACPI (MADT) for SMP configuration information
    mapped APIC to ffffb000 (fee00000)
    mapped IOAPIC to ffffa000 (fec00000)
    Allocating PCI resources starting at 80000000 (gap: 7ff00000:7ed00000)
    PERCPU: Allocating 38940 bytes of per cpu data
    NR_CPUS: 4, nr_cpu_ids: 4, nr_node_ids 1
    Built 1 zonelists in Zone order, mobility grouping on. Total pages: 519809
    Kernel command line: video=vesafb:mtrr,ywrap vga=773 ro root=/dev/sda1
    Enabling fast FPU save and restore... done.
    Enabling unmasked SIMD FPU exception support... done.
    Initializing CPU#0
    CPU 0 irqstacks, hard=c0478000 soft=c0474000
    PID hash table entries: 4096 (order: 12, 16384 bytes)
    TSC: PIT calibration confirmed by PMTIMER.
    TSC: using PMTIMER calibration value
    Detected 2405.452 MHz processor.
    Console: colour dummy device 80x25
    console [tty0] enabled
    Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
    Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
    Memory: 2073644k/2096000k available (2377k kernel code, 21180k reserved, 857k data, 272k init, 1178496k highmem)
    virtual kernel memory layout:
    fixmap : 0xfff85000 - 0xfffff000 ( 488 kB)
    pkmap : 0xff800000 - 0xffc00000 (4096 kB)
    vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB)
    lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
    .init : 0xc042d000 - 0xc0471000 ( 272 kB)
    .data : 0xc0352618 - 0xc0428bb8 ( 857 kB)
    .text : 0xc0100000 - 0xc0352618 (2377 kB)
    Checking if this processor honours the WP bit even in supervisor mode...Ok.
    CPA: page pool initialized 1 of 1 pages preallocated
    SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
    Calibrating delay loop (skipped), value calculated using timer frequency.. 4810.90 BogoMIPS (lpj=2405452)
    Mount-cache hash table entries: 512
    CPU: Trace cache: 12K uops, L1 D cache: 8K
    CPU: L2 cache: 512K
    CPU: Physical Processor ID: 0
    Checking 'hlt' instruction... OK.
    Freeing SMP alternatives: 10k freed
    ACPI: Core revision 20080609
    ENABLING IO-APIC IRQs
    ...TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
    CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
    CPU 1 irqstacks, hard=c0479000 soft=c0475000
    Booting processor 1/6 ip 6000
    Initializing CPU#1
    Calibrating delay using timer specific routine.. 4810.31 BogoMIPS (lpj=2405156)
    CPU: Trace cache: 12K uops, L1 D cache: 8K
    CPU: L2 cache: 512K
    CPU: Physical Processor ID: 3
    x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
    CPU1: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
    checking TSC synchronization [CPU#0 -> CPU#1]: passed.
    CPU 2 irqstacks, hard=c047a000 soft=c0476000
    Booting processor 2/1 ip 6000
    Initializing CPU#2
    Calibrating delay using timer specific routine.. 4810.28 BogoMIPS (lpj=2405141)
    CPU: Trace cache: 12K uops, L1 D cache: 8K
    CPU: L2 cache: 512K
    CPU: Physical Processor ID: 0
    x86 PAT enabled: cpu 2, old 0x7040600070406, new 0x7010600070106
    CPU2: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
    checking TSC synchronization [CPU#0 -> CPU#2]: passed.
    CPU 3 irqstacks, hard=c047b000 soft=c0477000
    Booting processor 3/7 ip 6000
    Initializing CPU#3
    Calibrating delay using timer specific routine.. 4810.31 BogoMIPS (lpj=2405159)
    CPU: Trace cache: 12K uops, L1 D cache: 8K
    CPU: L2 cache: 512K
    CPU: Physical Processor ID: 3
    x86 PAT enabled: cpu 3, old 0x7040600070406, new 0x7010600070106
    CPU3: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
    checking TSC synchronization [CPU#0 -> CPU#3]: passed.
    Brought up 4 CPUs
    Total of 4 processors activated (19241.81 BogoMIPS).
    net_namespace: 296 bytes
    NET: Registered protocol family 16
    No dock devices found.
    ACPI: bus type pci registered
    PCI: PCI BIOS revision 2.10 entry at 0xfb7f0, last bus=3
    PCI: Using configuration type 1 for base access
    ACPI: EC: Look up EC in DSDT
    ACPI: Interpreter enabled
    ACPI: (supports S0 S5)
    ACPI: Using IOAPIC for interrupt routing
    ACPI: PCI Root Bridge [PCI0] (0000:00)
    PCI: 0000:00:00.0 reg 10 32bit mmio: [f0000000, f1ffffff]
    PCI: 0000:00:1d.0 reg 20 io port: [bc00, bc1f]
    PCI: 0000:00:1d.1 reg 20 io port: [b000, b01f]
    PCI: 0000:00:1d.2 reg 20 io port: [b400, b41f]
    PCI: 0000:00:1d.3 reg 20 io port: [b800, b81f]
    PCI: 0000:00:1d.7 reg 10 32bit mmio: [f7100000, f71003ff]
    pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
    pci 0000:00:1d.7: PME# disabled
    pci 0000:00:1f.0: Force enabled HPET at 0xfed00000
    pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
    pci 0000:00:1f.0: quirk: region 0480-04bf claimed by ICH4 GPIO
    PCI: 0000:00:1f.1 reg 10 io port: [0, 7]
    PCI: 0000:00:1f.1 reg 14 io port: [0, 3]
    PCI: 0000:00:1f.1 reg 18 io port: [0, 7]
    PCI: 0000:00:1f.1 reg 1c io port: [0, 3]
    PCI: 0000:00:1f.1 reg 20 io port: [f000, f00f]
    PCI: 0000:00:1f.1 reg 24 32bit mmio: [0, 3ff]
    PCI: 0000:00:1f.2 reg 10 io port: [c000, c007]
    PCI: 0000:00:1f.2 reg 14 io port: [c400, c403]
    PCI: 0000:00:1f.2 reg 18 io port: [c800, c807]
    PCI: 0000:00:1f.2 reg 1c io port: [cc00, cc03]
    PCI: 0000:00:1f.2 reg 20 io port: [d000, d00f]
    PCI: 0000:00:1f.3 reg 20 io port: [500, 51f]
    PCI: 0000:00:1f.5 reg 10 io port: [d800, d8ff]
    PCI: 0000:00:1f.5 reg 14 io port: [dc00, dc3f]
    PCI: 0000:00:1f.5 reg 18 32bit mmio: [f7101000, f71011ff]
    PCI: 0000:00:1f.5 reg 1c 32bit mmio: [f7102000, f71020ff]
    pci 0000:00:1f.5: PME# supported from D0 D3hot D3cold
    pci 0000:00:1f.5: PME# disabled
    PCI: 0000:01:00.0 reg 10 32bit mmio: [f2000000, f2ffffff]
    PCI: 0000:01:00.0 reg 14 32bit mmio: [e0000000, efffffff]
    PCI: 0000:01:00.0 reg 18 32bit mmio: [f3000000, f3ffffff]
    PCI: 0000:01:00.0 reg 30 32bit mmio: [0, 1ffff]
    PCI: bridge 0000:00:01.0 32bit mmio: [f2000000, f4ffffff]
    PCI: bridge 0000:00:01.0 32bit mmio pref: [e0000000, efffffff]
    PCI: 0000:02:01.0 reg 10 32bit mmio: [f7000000, f701ffff]
    PCI: 0000:02:01.0 reg 18 io port: [a000, a01f]
    pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
    pci 0000:02:01.0: PME# disabled
    PCI: bridge 0000:00:03.0 io port: [a000, afff]
    PCI: bridge 0000:00:03.0 32bit mmio: [f7000000, f70fffff]
    PCI: 0000:03:03.0 reg 10 32bit mmio: [f6008000, f60087ff]
    PCI: 0000:03:03.0 reg 14 32bit mmio: [f6000000, f6003fff]
    pci 0000:03:03.0: supports D1
    pci 0000:03:03.0: supports D2
    pci 0000:03:03.0: PME# supported from D0 D1 D2 D3hot
    pci 0000:03:03.0: PME# disabled
    PCI: 0000:03:0a.0 reg 10 io port: [8000, 80ff]
    PCI: 0000:03:0a.0 reg 14 64bit mmio: [f6004000, f6005fff]
    PCI: 0000:03:0a.0 reg 1c io port: [8400, 84ff]
    PCI: 0000:03:0a.0 reg 30 32bit mmio: [0, 7ffff]
    PCI: 0000:03:0a.1 reg 10 io port: [8800, 88ff]
    PCI: 0000:03:0a.1 reg 14 64bit mmio: [f6006000, f6007fff]
    PCI: 0000:03:0a.1 reg 1c io port: [8c00, 8cff]
    PCI: 0000:03:0a.1 reg 30 32bit mmio: [0, 7ffff]
    PCI: 0000:03:0b.0 reg 10 io port: [9000, 901f]
    PCI: 0000:03:0b.1 reg 10 io port: [9400, 9407]
    PCI: 0000:03:0d.0 reg 10 io port: [9800, 987f]
    PCI: 0000:03:0d.0 reg 14 32bit mmio: [f6009000, f600907f]
    PCI: 0000:03:0d.0 reg 30 32bit mmio: [0, 1ffff]
    pci 0000:03:0d.0: supports D1
    pci 0000:03:0d.0: supports D2
    pci 0000:03:0d.0: PME# supported from D0 D1 D2 D3hot D3cold
    pci 0000:03:0d.0: PME# disabled
    pci 0000:00:1e.0: transparent bridge
    PCI: bridge 0000:00:1e.0 io port: [8000, 9fff]
    PCI: bridge 0000:00:1e.0 32bit mmio: [f5000000, f6ffffff]
    bus 00 -> node 0
    ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
    ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
    ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 7 9 10 11 12 14 15)
    ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *9 10 11 12 14 15)
    ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15)
    ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 7 9 10 11 12 14 15)
    ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 *11 12 14 15)
    ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 *11 12 14 15)
    ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 *5 7 9 10 11 12 14 15)
    ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 *9 10 11 12 14 15)
    Linux Plug and Play Support v0.97 (c) Adam Belay
    pnp: PnP ACPI init
    ACPI: bus type pnp registered
    pnp: PnP ACPI: found 16 devices
    ACPI: ACPI bus type pnp unregistered
    SCSI subsystem initialized
    libata version 3.00 loaded.
    usbcore: registered new interface driver usbfs
    usbcore: registered new interface driver hub
    usbcore: registered new device driver usb
    PCI: Using ACPI for IRQ routing
    hpet clockevent registered
    hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
    hpet0: 3 64-bit timers, 14318180 Hz
    ACPI: RTC can wake from S4
    system 00:01: ioport range 0xb78-0xb7b has been reserved
    system 00:01: ioport range 0xf78-0xf7b has been reserved
    system 00:01: ioport range 0xa78-0xa7b has been reserved
    system 00:01: ioport range 0xe78-0xe7b has been reserved
    system 00:01: ioport range 0xbbc-0xbbf has been reserved
    system 00:01: ioport range 0xfbc-0xfbf has been reserved
    system 00:01: ioport range 0x4d0-0x4d1 has been reserved
    system 00:0d: ioport range 0x400-0x4bf could not be reserved
    system 00:0d: ioport range 0x295-0x296 has been reserved
    system 00:0f: iomem range 0xd9e00-0xdbfff has been reserved
    system 00:0f: iomem range 0xf0000-0xf7fff could not be reserved
    system 00:0f: iomem range 0xf8000-0xfbfff could not be reserved
    system 00:0f: iomem range 0xfc000-0xfffff could not be reserved
    system 00:0f: iomem range 0x7fee0000-0x7fefffff could not be reserved
    system 00:0f: iomem range 0x0-0x9ffff could not be reserved
    system 00:0f: iomem range 0x100000-0x7fedffff could not be reserved
    system 00:0f: iomem range 0xfec00000-0xfec00fff could not be reserved
    system 00:0f: iomem range 0xfec01000-0xfed8ffff could not be reserved
    system 00:0f: iomem range 0xfee00000-0xfee00fff could not be reserved
    system 00:0f: iomem range 0xffb00000-0xffb7ffff could not be reserved
    system 00:0f: iomem range 0xfff00000-0xffffffff could not be reserved
    system 00:0f: iomem range 0xe0000-0xeffff has been reserved
    pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
    pci 0000:00:01.0: IO window: disabled
    pci 0000:00:01.0: MEM window: 0xf2000000-0xf4ffffff
    pci 0000:00:01.0: PREFETCH window: 0x000000e0000000-0x000000efffffff
    pci 0000:00:03.0: PCI bridge, secondary bus 0000:02
    pci 0000:00:03.0: IO window: 0xa000-0xafff
    pci 0000:00:03.0: MEM window: 0xf7000000-0xf70fffff
    pci 0000:00:03.0: PREFETCH window: disabled
    pci 0000:00:1e.0: PCI bridge, secondary bus 0000:03
    pci 0000:00:1e.0: IO window: 0x8000-0x9fff
    pci 0000:00:1e.0: MEM window: 0xf5000000-0xf6ffffff
    pci 0000:00:1e.0: PREFETCH window: 0x00000080000000-0x000000801fffff
    pci 0000:00:1e.0: setting latency timer to 64
    bus: 00 index 0 io port: [0, ffff]
    bus: 00 index 1 mmio: [0, ffffffff]
    bus: 01 index 0 mmio: [0, 0]
    bus: 01 index 1 mmio: [f2000000, f4ffffff]
    bus: 01 index 2 mmio: [e0000000, efffffff]
    bus: 01 index 3 mmio: [0, 0]
    bus: 02 index 0 io port: [a000, afff]
    bus: 02 index 1 mmio: [f7000000, f70fffff]
    bus: 02 index 2 mmio: [0, 0]
    bus: 02 index 3 mmio: [0, 0]
    bus: 03 index 0 io port: [8000, 9fff]
    bus: 03 index 1 mmio: [f5000000, f6ffffff]
    bus: 03 index 2 mmio: [80000000, 801fffff]
    bus: 03 index 3 io port: [0, ffff]
    bus: 03 index 4 mmio: [0, ffffffff]
    ....

    --
    J.A. Magallon \ Software is like sex:
    \ It's better when it's free
    Mandriva Linux release 2009.0 (Cooker) for i586
    Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:

    > one have gran < 1M
    >
    > reg00: base=0xd8000000 (3456MB), size= 128MB: uncachable, count=1
    > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
    > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
    > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
    > reg05: base=0xd7f80000 (3455MB), size= 512KB: uncachable, count=1
    >
    > will get
    >
    > Found optimal setting for mtrr clean up
    > gran_size: 512K chunk_size: 2M num_reg: 7 lose RAM: 0G
    > range0: 0000000000000000 - 00000000d8000000
    > Setting variable MTRR 0, base: 0GB, range: 2GB, type WB
    > Setting variable MTRR 1, base: 2GB, range: 1GB, type WB
    > Setting variable MTRR 2, base: 3GB, range: 256MB, type WB
    > Setting variable MTRR 3, base: 3328MB, range: 128MB, type WB
    > hole: 00000000d7f00000 - 00000000d7f80000
    > Setting variable MTRR 4, base: 3455MB, range: 512KB, type UC
    > rangeX: 0000000100000000 - 0000000128000000
    > Setting variable MTRR 5, base: 4GB, range: 512MB, type WB
    > Setting variable MTRR 6, base: 4608MB, range: 128MB, type WB
    >
    > so start from 64k instead of 1M
    >
    >


    Also, on a 64 bit box with 4Gb, it gives this:

    cicely:~# cat /proc/mtrr
    reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1

    Patch below cleans up formatting, with space for big bases and sizes (64 Gb).

    diff -p -up arch/x86/kernel/cpu/mtrr/if.c.orig arch/x86/kernel/cpu/mtrr/if.c
    --- arch/x86/kernel/cpu/mtrr/if.c.orig 2008-10-03 00:16:37.000000000 +0200
    +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    @@ -16,7 +16,7 @@
    static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    {
    "uncachable", /* 0 */
    - "write-combining", /* 1 */
    + "write-combine", /* 1 */
    "?", /* 2 */
    "?", /* 3 */
    "write-through", /* 4 */
    @@ -405,9 +405,9 @@ static int mtrr_seq_show(struct seq_file
    }
    /* RED-PEN: base can be > 32bit */
    len += seq_printf(seq,
    - "reg%02i: base=0x%05lx000 (%4luMB), size=%4lu%cB: %s, count=%d\n",
    + "reg%02i: base=0x%06lx000 (%5luMB), size=%5lu%cB, count=%d: %s\n",
    i, base, base >> (20 - PAGE_SHIFT), size, factor,
    - mtrr_attrib_to_str(type), mtrr_usage_table[i]);
    + mtrr_usage_table[i], mtrr_attrib_to_str(type));
    }
    }
    return 0;

    --
    J.A. Magallon \ Software is like sex:
    \ It's better when it's free
    Mandriva Linux release 2009.0 (Cooker) for i586
    Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón wrote:
    > On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:
    >
    >>
    >> so start from 64k instead of 1M
    >>

    >
    > Or there is something I don't catch about mtrrs, or it still does silly
    > things.
    >
    > I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
    >
    > werewolf:/proc> cat mtrr
    > reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
    > reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
    > reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
    > reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
    > reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1
    > reg05: base=0x7c000000 (1984MB), size= 64MB: write-back, count=1
    > reg06: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    >
    > So it adds a last WB zone, but substracts the last 1Mb. (Why do
    > I have that stupid uncacheable mb ? probably a bios issue...)
    > But those two 64 mb zones could be add to a 128Mb, that new one
    > with previous to 256Mb and so on, giving something like:
    >
    > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    > reg01: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    >
    > Is this incorrect ?
    >


    can you boot with mtrr_cleanup_debug?

    also what is /proc/mtrr with disable_mtrr_cleanup?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, Oct 2, 2008 at 3:32 PM, J.A. Magallón wrote:
    > On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:
    >
    > Also, on a 64 bit box with 4Gb, it gives this:
    >
    > cicely:~# cat /proc/mtrr
    > reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    > reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
    >

    boundary handling may have problem...

    should have
    > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1


    can you post /proc/mtrr with disable_mtrr_cleanup?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, Oct 2, 2008 at 3:39 PM, Yinghai Lu wrote:
    > On Thu, Oct 2, 2008 at 3:32 PM, J.A. Magallón wrote:
    >> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:
    >>
    >> Also, on a 64 bit box with 4Gb, it gives this:
    >>
    >> cicely:~# cat /proc/mtrr
    >> reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    >> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    >> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    >> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    >> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
    >>

    > boundary handling may have problem...


    can you try

    diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
    index ef64128..70beb13 100644
    --- a/arch/x86/kernel/cpu/mtrr/main.c
    +++ b/arch/x86/kernel/cpu/mtrr/main.c
    @@ -1044,7 +1044,7 @@ second_try:
    hole_sizek = range0_sizek - state->range_sizek - second_sizek;

    /* hole size should be less than half of range0 size */
    - if (hole_sizek > (range0_sizek >> 1) &&
    + if (hole_sizek >= (range0_sizek >> 1) &&
    range0_sizek >= chunk_sizek) {
    range0_sizek -= chunk_sizek;
    second_sizek = 0;

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, 2 Oct 2008 15:33:10 -0700, "Yinghai Lu" wrote:

    > On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón wrote:
    > > On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:
    > >
    > >>
    > >> so start from 64k instead of 1M
    > >>

    > >
    > > Or there is something I don't catch about mtrrs, or it still does silly
    > > things.
    > >
    > > I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
    > >
    > > werewolf:/proc> cat mtrr
    > > reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
    > > reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
    > > reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
    > > reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
    > > reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1
    > > reg05: base=0x7c000000 (1984MB), size= 64MB: write-back, count=1
    > > reg06: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    > >
    > > So it adds a last WB zone, but substracts the last 1Mb. (Why do
    > > I have that stupid uncacheable mb ? probably a bios issue...)
    > > But those two 64 mb zones could be add to a 128Mb, that new one
    > > with previous to 256Mb and so on, giving something like:
    > >
    > > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    > > reg01: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    > >
    > > Is this incorrect ?
    > >

    >
    > can you boot with mtrr_cleanup_debug?
    >


    I don't have such option in my kernel, this is -rc8-git3.

    > also what is /proc/mtrr with disable_mtrr_cleanup?
    >
    >

    Yeah, it goes right on the Xeon:

    reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    reg01: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1

    Will try your patch now.

    --
    J.A. Magallon \ Software is like sex:
    \ It's better when it's free
    Mandriva Linux release 2009.0 (Cooker) for i586
    Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, Oct 2, 2008 at 3:33 PM, Yinghai Lu wrote:
    > On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón wrote:
    >> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:
    >>
    >>>
    >>> so start from 64k instead of 1M
    >>>

    >>
    >> Or there is something I don't catch about mtrrs, or it still does silly
    >> things.
    >>
    >> I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
    >>
    >> werewolf:/proc> cat mtrr
    >> reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
    >> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
    >> reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
    >> reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
    >> reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1
    >> reg05: base=0x7c000000 (1984MB), size= 64MB: write-back, count=1
    >> reg06: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    >>
    >> So it adds a last WB zone, but substracts the last 1Mb. (Why do
    >> I have that stupid uncacheable mb ? probably a bios issue...)
    >> But those two 64 mb zones could be add to a 128Mb, that new one
    >> with previous to 256Mb and so on, giving something like:
    >>
    >> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    >> reg01: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    >>
    >> Is this incorrect ?
    >>

    >
    > can you boot with mtrr_cleanup_debug?
    >
    > also what is /proc/mtrr with disable_mtrr_cleanup?


    are you on latest tip/master?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, 2 Oct 2008 15:52:11 -0700, "Yinghai Lu" wrote:

    > On Thu, Oct 2, 2008 at 3:33 PM, Yinghai Lu wrote:
    > > On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón wrote:
    > >> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:
    > >>
    > >>>
    > >>> so start from 64k instead of 1M
    > >>>
    > >>
    > >> Or there is something I don't catch about mtrrs, or it still does silly
    > >> things.
    > >>
    > >> I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
    > >>
    > >> werewolf:/proc> cat mtrr
    > >> reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
    > >> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
    > >> reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
    > >> reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
    > >> reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1
    > >> reg05: base=0x7c000000 (1984MB), size= 64MB: write-back, count=1
    > >> reg06: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    > >>
    > >> So it adds a last WB zone, but substracts the last 1Mb. (Why do
    > >> I have that stupid uncacheable mb ? probably a bios issue...)
    > >> But those two 64 mb zones could be add to a 128Mb, that new one
    > >> with previous to 256Mb and so on, giving something like:
    > >>
    > >> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    > >> reg01: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    > >>
    > >> Is this incorrect ?
    > >>

    > >
    > > can you boot with mtrr_cleanup_debug?
    > >
    > > also what is /proc/mtrr with disable_mtrr_cleanup?

    >
    > are you on latest tip/master?
    >


    No, I use rc8-git3 with your patches (the small gran_size series and the
    parameter rename, except the debug one) manually applied.

    --
    J.A. Magallon \ Software is like sex:
    \ It's better when it's free
    Mandriva Linux release 2009.0 (Cooker) for i586
    Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, Oct 2, 2008 at 4:00 PM, J.A. Magallón wrote:
    > On Thu, 2 Oct 2008 15:52:11 -0700, "Yinghai Lu" wrote:
    >
    >> On Thu, Oct 2, 2008 at 3:33 PM, Yinghai Lu wrote:
    >> > On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón wrote:
    >> >> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:
    >> >>
    >> >>>
    >> >>> so start from 64k instead of 1M
    >> >>>
    >> >>
    >> >> Or there is something I don't catch about mtrrs, or it still does silly
    >> >> things.
    >> >>
    >> >> I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
    >> >>
    >> >> werewolf:/proc> cat mtrr
    >> >> reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
    >> >> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
    >> >> reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
    >> >> reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
    >> >> reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1
    >> >> reg05: base=0x7c000000 (1984MB), size= 64MB: write-back, count=1
    >> >> reg06: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    >> >>
    >> >> So it adds a last WB zone, but substracts the last 1Mb. (Why do
    >> >> I have that stupid uncacheable mb ? probably a bios issue...)
    >> >> But those two 64 mb zones could be add to a 128Mb, that new one
    >> >> with previous to 256Mb and so on, giving something like:
    >> >>
    >> >> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    >> >> reg01: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1
    >> >>
    >> >> Is this incorrect ?
    >> >>
    >> >
    >> > can you boot with mtrr_cleanup_debug?
    >> >
    >> > also what is /proc/mtrr with disable_mtrr_cleanup?

    >>
    >> are you on latest tip/master?
    >>

    >
    > No, I use rc8-git3 with your patches (the small gran_size series and the
    > parameter rename, except the debug one) manually applied.
    >


    ah..
    please pick up all of them from tip/master...

    x86: don't need to go to chunksize to 4G
    x86: mtrr_cleanup optimization, v2
    x86: add mtrr_cleanup_debug command line
    x86: cleanup, remove extra ifdef
    x86: mtrr_cleanup hole size should be less than half of chunk_size, v2
    x86: mtrr_cleanup safe to get more spare regs now
    x86: mtrr_cleanup prepare to make gran_size to less 1M
    x86: mtrr_cleanup try gran_size to less than 1M
    x86: change MTRR_SANITIZER to def_bool y


    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, 2 Oct 2008 15:39:34 -0700, "Yinghai Lu" wrote:

    > On Thu, Oct 2, 2008 at 3:32 PM, J.A. Magallón wrote:
    > > On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu wrote:
    > >
    > > Also, on a 64 bit box with 4Gb, it gives this:
    > >
    > > cicely:~# cat /proc/mtrr
    > > reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    > > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    > > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    > > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    > > reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
    > >

    > boundary handling may have problem...
    >
    > should have
    > > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1


    should not this ^^^^^ be 4096MB ??

    > > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    > > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    > > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1

    >
    > can you post /proc/mtrr with disable_mtrr_cleanup?
    >


    Oops, sorry, this is without cleanup. This is a distro kernel and is built
    but not enable by deafult. As it is rc7, I will use 'enble_mtrr_cleanup' :

    cicely:~# cat /proc/mtrr
    reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1

    I have lost 2Gb ?

    cicely:~# free
    total used free shared buffers cached
    Mem: 3755568 182348 3573220 0 14024 72716
    -/+ buffers/cache: 95608 3659960

    I can't easily try your patch, this is a distro kernel.
    I will get the src.rpm...

    Ahhhhh....

    This is a dual opteron board. dmidecode says:

    Handle 0x0026, DMI type 16, 15 bytes
    Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: Single-bit ECC
    Maximum Capacity: 8 GB
    Error Information Handle: Not Provided
    Number Of Devices: 8

    So it maps one Opteron memory in first 4Gb and the other on the second 4Gb.
    So I should have 2Gb@0 and 2Gb@4Gb.
    What I don't know is why the bios eats up 256Mb.

    --
    J.A. Magallon \ Software is like sex:
    \ It's better when it's free
    Mandriva Linux release 2009.0 (Cooker) for i586
    Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, Oct 2, 2008 at 4:20 PM, J.A. Magallón wrote:
    > On Thu, 2 Oct 2008 15:39:34 -0700, "Yinghai Lu" wrote:
    >
    > Oops, sorry, this is without cleanup. This is a distro kernel and is built
    > but not enable by deafult. As it is rc7, I will use 'enble_mtrr_cleanup' :
    >
    > cicely:~# cat /proc/mtrr
    > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    >
    > I have lost 2Gb ?


    that is memhole

    >
    > cicely:~# free
    > total used free shared buffers cached
    > Mem: 3755568 182348 3573220 0 14024 72716
    > -/+ buffers/cache: 95608 3659960
    >
    > I can't easily try your patch, this is a distro kernel.
    > I will get the src.rpm...


    just pull tip/master, and use your config from /boot/config....

    >
    > Ahhhhh....
    >
    > This is a dual opteron board. dmidecode says:
    >
    > Handle 0x0026, DMI type 16, 15 bytes
    > Physical Memory Array
    > Location: System Board Or Motherboard
    > Use: System Memory
    > Error Correction Type: Single-bit ECC
    > Maximum Capacity: 8 GB
    > Error Information Handle: Not Provided
    > Number Of Devices: 8
    >
    > So it maps one Opteron memory in first 4Gb and the other on the second 4Gb.
    > So I should have 2Gb@0 and 2Gb@4Gb.
    > What I don't know is why the bios eats up 256Mb.


    check if you enable memhole remapping in BIOS.

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    | From: Yinghai Lu

    | can you boot with mtrr_cleanup_debug?
    |
    | also what is /proc/mtrr with disable_mtrr_cleanup?

    Shouldn't mtrr_cleanup_debug show the pre-cleanup MTRR settings?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Thu, Oct 2, 2008 at 4:55 PM, D. Hugh Redelmeier wrote:
    > | From: Yinghai Lu
    >
    > | can you boot with mtrr_cleanup_debug?
    > |
    > | also what is /proc/mtrr with disable_mtrr_cleanup?
    >
    > Shouldn't mtrr_cleanup_debug show the pre-cleanup MTRR settings?


    yeah, will add some line about that.

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    Ingo Molnar wrote:
    > * J.A. Magallón wrote:
    >
    >> Also, on a 64 bit box with 4Gb, it gives this:
    >>
    >> cicely:~# cat /proc/mtrr
    >> reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    >> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    >> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    >> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    >> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
    >>
    >> Patch below cleans up formatting, with space for big bases and sizes (64 Gb).

    >
    > applied to tip/x86/mtrr, thanks!
    >
    >> +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    >> @@ -16,7 +16,7 @@
    >> static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    >> {
    >> "uncachable", /* 0 */
    >> - "write-combining", /* 1 */
    >> + "write-combine", /* 1 */

    >
    > hm, maybe this bit could confuse versions of Xorg that modifies
    > /proc/mtrr - i.e. this could be part of the ABI towards user-space.
    > We'll see.
    >


    This *IS* part of the ABI toward userspace, although I think Xorg uses
    the ioctl() interface.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 2 1 2 LastLast