Multiple *BAD*gran_size messages
FedoraForum.org - Fedora Support Forums and Community
Results 1 to 6 of 6
  1. #1
    Join Date
    Aug 2012
    Location
    Ukraine
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Multiple *BAD*gran_size messages

    My dmesg has multiple *BAD*gran_size messages. As follows from specific of the messages there is an issue at RAM level. I use PAE kernel, memory has been detected completely. More details:

    dmesg: http://forums.fedoraforum.org/attach...0&d=1345363807

    uname -a
    Code:
    Linux hostname 3.4.7-1.fc16.i686.PAE #1 SMP Mon Jul 30 16:45:15 UTC 2012 i686 i686 i386 GNU/Linux
    cat /proc/meminfo
    Code:
    MemTotal:       16492496 kB
    MemFree:        14845144 kB
    Buffers:           99448 kB
    Cached:           234036 kB
    SwapCached:            0 kB
    Active:           989504 kB
    Inactive:         551368 kB
    Active(anon):     822892 kB
    Inactive(anon):   392528 kB
    Active(file):     166612 kB
    Inactive(file):   158840 kB
    Unevictable:        3256 kB
    Mlocked:            3256 kB
    HighTotal:      15766764 kB
    HighFree:       14304520 kB
    LowTotal:         725732 kB
    LowFree:          540624 kB
    SwapTotal:             0 kB
    SwapFree:              0 kB
    Dirty:                68 kB
    Writeback:             0 kB
    AnonPages:       1210580 kB
    Mapped:            57052 kB
    Shmem:              5768 kB
    Slab:              48236 kB
    SReclaimable:      31740 kB
    SUnreclaim:        16496 kB
    KernelStack:        3256 kB
    PageTables:        13408 kB
    NFS_Unstable:          0 kB
    Bounce:                0 kB
    WritebackTmp:          0 kB
    CommitLimit:     8246248 kB
    Committed_AS:    4037808 kB
    VmallocTotal:     122880 kB
    VmallocUsed:       40236 kB
    VmallocChunk:      81012 kB
    HardwareCorrupted:     0 kB
    AnonHugePages:    704512 kB
    HugePages_Total:       0
    HugePages_Free:        0
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       2048 kB
    DirectMap4k:       12280 kB
    DirectMap2M:      894976 kB
    If I understand right something is wrong at MTRR level. Thus here is my cat /proc/mtrr:

    Code:
    reg00: base=0x000000000 (    0MB), size=16384MB, count=1: write-back
    reg01: base=0x400000000 (16384MB), size=  512MB, count=1: write-back
    reg02: base=0x0e0000000 ( 3584MB), size=  512MB, count=1: uncachable
    reg03: base=0x0dc000000 ( 3520MB), size=   64MB, count=1: uncachable
    reg04: base=0x0db800000 ( 3512MB), size=    8MB, count=1: uncachable
    reg05: base=0x41f800000 (16888MB), size=    8MB, count=1: uncachable
    reg06: base=0x41f600000 (16886MB), size=    2MB, count=1: uncachable
    Please, help.

  2. #2
    Join Date
    Dec 2006
    Posts
    2,088
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Multiple *BAD*gran_size messages

    You can test your memory with Memtest86+, but your BIOS seems to be broken.

    If you have 16 GiB of memory you should consider installing a 64 bit operating system, because a (single) 32 bit process isn't allowed to use more than 3 GiB of memory even with a PAE kernel.

  3. #3
    Join Date
    Aug 2012
    Location
    Ukraine
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Multiple *BAD*gran_size messages

    Quote Originally Posted by george_toolan
    You can test your memory with Memtest86+, but your BIOS seems to be broken.

    If you have 16 GiB of memory you should consider installing a 64 bit operating system, because a (single) 32 bit process isn't allowed to use more than 3 GiB of memory even with a PAE kernel.
    Dear george_toolan, thank you very much for your early reply!

    I'll try to test the memory by Memtest86+ tomorrow and post a report.

    It's not necessary for me to have 3 Gb for a process as this is regular web- mail- proxy-server and there are no processes which can consume so much of RAM per process. PAE-kernel is OK for me, I understood it during installation well. For some reasons I need 32bit OS, but not 64bit, due to some software requirements.

    Thanks again!

  4. #4
    Join Date
    Aug 2012
    Location
    Ukraine
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Smile Re: Multiple *BAD*gran_size messages

    Quote Originally Posted by george_toolan
    You can test your memory with Memtest86+, but your BIOS seems to be broken.
    OK. Memory check shows my RAM is OK.

    Updating to newer version of BIOS for my Intel DH77EB motherboard (from v.0053 to v.0075) gave me no positive result, as it follows from dmesg: dmesg_0075.txt - the problem still the same.

    Afterwards I paid attention to some dmesg messages:

    Code:
    [    0.000000] mtrr_cleanup: can not find optimal value
    [    0.000000] please specify mtrr_gran_size/mtrr_chunk_size
    I have decided to enable MTRR sanitizer and specify values for mtrr_gran_size and mtrr_chunk_size by appending to boot options in /boot/grub2/grub.cfg and /etc/default/grub the following parameters:

    Code:
    enable_mtrr_cleanup mtrr_spare_reg_nr=1 mtrr_gran_size=32M mtrr_chunk_size=128M
    This MTRR options solved my problem completely, only one dmesg message appears:

    Code:
    [    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 31MB of RAM.
    Thus 31 Mb from 16Gb of my RAM gone, but for another things I'm happy, dmesg looks quite clean: dmesg_OK.txt and now we can see:

    cat /proc/mtrr
    Code:
    reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
    reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
    reg02: base=0x0c0000000 ( 3072MB), size=  512MB, count=1: write-back
    reg03: base=0x0da000000 ( 3488MB), size=   32MB, count=1: uncachable
    reg04: base=0x0dc000000 ( 3520MB), size=   64MB, count=1: uncachable
    reg05: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
    reg06: base=0x200000000 ( 8192MB), size= 8192MB, count=1: write-back
    reg07: base=0x400000000 (16384MB), size=  512MB, count=1: write-back
    reg08: base=0x41e000000 (16864MB), size=   32MB, count=1: uncachable
    reg09: base=0x0e0000000 ( 3584MB), size=  256MB, count=1: write-combining
    Thank you dear george_toolan for trying help me!

    The problem is solved.

  5. #5
    Join Date
    Oct 2010
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up Re: Multiple *BAD*gran_size messages

    Hi,

    your post helped me a lot, thanks.

    I used too those two sites :
    http://www.mjmwired.net/kernel/Docum...parameters.txt
    and
    http://my-fuzzy-logic.de/blog/index....-problems.html

    The second one was very helpful to understand a bit more what were those 'gran_size: xM' messages.
    The light came with this sentence :
    "The sanitizer was not able to find an optimal mtrr setup, but he kindly printed a long list with possible setups for me into the buffer."

    So it's easy...
    In my case the minimum RAM I could lose was 8M :
    [ 0.000000] gran_size: 8M chunk_size: 32M num_reg: 10 lose cover RAM: 8M
    [ 0.000000] gran_size: 8M chunk_size: 64M num_reg: 10 lose cover RAM: 8M
    [ 0.000000] gran_size: 8M chunk_size: 128M num_reg: 10 lose cover RAM: 8M
    [ 0.000000] gran_size: 8M chunk_size: 256M num_reg: 10 lose cover RAM:

    My choice is gran_size: 8M chunk_size: 64M , but now the question is : what is the 'optimal' chunk_size ? a big one or a small one ?
    By the way, apprently, I'm losing only 2M :
    WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 2MB of RAM.

    And a note for the road : in grub write 8M not 8, it will freeze up everything (thanks to the 'e' command I could modify grub.cfg on the fly)

    O'
    ~~ Fedora 17 - 64 bits
    ~~ 10 Gb
    ~~ CPU: i7-3517U

  6. #6
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,345
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Multiple *BAD*gran_size messages

    I suspect you need a BIOS update...

    Depending on the age of the motherboard, it might not handle the memory you have (might be a bit too large per unit). Doesn't mean you can't work around it, but loosing memory is a sign that it exceeds the capacity of the CPU.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •