Announcement

Collapse
No announcement yet.

bad MTRR setup, according to DRM

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bad MTRR setup, according to DRM

    Hi,
    I'm running X + DRI2 + KMS on i915 hardware (intel HD4500, actually) and I'm getting the following message in dmesg:
    Code:
    mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
    [drm] MTRR allocation failed.  Graphics performance may suffer.
    After some googling, It seems that I need an MTRR entry for video memory in write-combining mode, which I don't have according to /proc/mtrr.

    Code:
    reg00: base=0x000000000 (    0MB), size=32768MB, count=1: write-back
    reg01: base=0x0e0000000 ( 3584MB), size=  512MB, count=1: uncachable
    reg02: base=0x0ddc00000 ( 3548MB), size=    4MB, count=1: uncachable
    reg03: base=0x0de000000 ( 3552MB), size=   32MB, count=1: uncachable
    It seems this problem happens because of my 4GB RAM and maybe x86_64.
    It might be a kernel issue, so I tried the following options, as some users suggested:
    Code:
    CONFIG_X86_PAT=n
    CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
    That didn't fix it.

    But now I remember that some work about DRI2 was about moving from static to dynamic memory management (GEM objects).
    So, is this somehow related to the DRI2 transition? Or any ideas about how to fix that?

  • #2
    I'm having the same problems on a similar set up. Haven't tried CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 yet, but I will.

    I can get rid of the problem by disabling the "Memory Remap Feature" in BIOS. But that means I end up losing quite a bit of RAM.

    This problem has been discussed in the Xorg bugzilla;


    There's also a kernel bug,

    but it seems to be specific to i386 (not amd64 and claimed to be fixed in 2.6.26)

    There's also an Ubuntu bug,
    After upgrading my Laptop to 4GB RAM my MTRRs are set up in such a way that X can't set up a write-combining range for the video memory anymore, causing a noticable loss of performance /proc/mtrr with 2GB: reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x7f700000 (2039MB), size= 1MB: uncachable, count=1 reg02: base=0x7f800000 (2040MB), size= 8MB: uncachable, count=1 reg03: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 (last range added by ...

    where others still are reporting the same problem.

    I will do some more testing and file a new bug about this in the kernel.org bugzilla.

    Comment


    • #3
      There's another kernel bug open for MTRR problems on x86_64:

      Comment


      • #4
        Okay, setting CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 seems to work for me. I'm using 2.6.30-rc4.

        Comment


        • #5
          Not sure what distro you are using, but if it's ubuntu you can just boot with enable_mtrr_cleanup mtrr_spare_reg_nr=1 added to your grub command line for the same effect instead of recompiling the kernel.

          Comment


          • #6
            Code:
            CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
            CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
            I built linux 2.6.30-rc6 with these options, but the problem persists.
            But my dmesg contains the following:
            Code:
            mtrr_cleanup: can not find optimal value
            please specify mtrr_gran_size/mtrr_chunk_size
            What do these options mean?

            Comment

            Working...
            X