LinuxQuestions.org - mtrr allocation failed. Graphics performance may suffer. Intel hd2000 iGPU

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - mtrr allocation failed. Graphics performance may suffer. Intel hd2000 iGPU (https://www.linuxquestions.org/questions/slackware-14/mtrr-allocation-failed-graphics-performance-may-suffer-intel-hd2000-igpu-4175430429/)

mtrr allocation failed. Graphics performance may suffer. Intel hd2000 iGPU

Hi slackers.

Recently, during the boot time I've noticed the warning: "mtrr allocation failed, graphics performance may suffer". I was wondering if this is a serious problem? I've noticed that sometimes, during the HD video playback image would become choppy here and there, every now and then... Could the mtrr failed allocation cause that?

Here is the output of cat /proc/mtrr:

Code:

$ cat /proc/mtrr

reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back

reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back

reg02: base=0x0a7000000 ( 2672MB), size=  16MB, count=1: uncachable

reg03: base=0x0a8000000 ( 2688MB), size=  128MB, count=1: uncachable

reg04: base=0x0b0000000 ( 2816MB), size=  256MB, count=1: uncachable

reg05: base=0x0ffc00000 ( 4092MB), size=    4MB, count=1: write-protect

reg06: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back

reg07: base=0x140000000 ( 5120MB), size=  256MB, count=1: write-back

reg08: base=0x14fe00000 ( 5374MB), size=    2MB, count=1: uncachable

BTW I have intel's B940 processor with the hd2000 integrated GPU.
Cheers! ;)

I have this issue with intel sandy bridge with 13.37 and 14 as well. I have no solution, just wanted to let you know your not alone on this.

Looks like the problem is present for a long time now:
-RedHat bug report,
-possible workaround (I haven't test it yet).
There was a post on a RedHat bug report which says that problems (in Fedora Core 17) disappeared after upgrading the kernel to version 3.4.0. Too bad Pat didn't include 3.4 kernel to Slackware 14.0.
Old Fogie, thank you for your feedback... I'm sorry to hear you have the same problems... If I find a solution I will post it here. If someone already knows the solution to the problem please provide it, it will be much appreciated!

Adding enable_mtrr_cleanup mtrr_spare_reg_nr=1 to kernel parameters didn't work for me.

Thank you! Best regards.

Try the workaround, but also look in 'dmesg' for the full output, to see if there are any free registers. Of course, you can also compile your own kernel if you say it will fix it. Use the config file in /testing directory plus one of these guides to compile a new kernel:

http://docs.slackware.com/howtos:sla...git_repository
http://docs.slackware.com/howtos:sla...kernelbuilding

I know many people are afraid of it, but it can not only boost performance and stability, but also solve problems.

H_TeXMeX_H thank you for your suggestions and for the links... I did try the workaround but no success. mtrr values were the same and the dmesg part for the mtrr was the same:

Code:

# dmesg | grep -i mtrr

[    0.000000] MTRR default type: uncachable

[    0.000000] MTRR fixed ranges enabled:

[    0.000000] MTRR variable ranges enabled:

[    9.249779] mtrr: type mismatch for b0000000,10000000 old: write-back new: write-combining

[    9.249895] [drm] MTRR allocation failed.  Graphics performance may suffer.

I will try to compile the newer kernel, and then I will post the result.
Your help is appreciated! Best regards.

I'm running kernel 3.4.X series kernel since it was released. In fact I get this on all kernels 3.2.X thru 3.6.X. But I've settled in on 3.4.X as it's the only Linux kernel that seems to work right with my hardware. I hope it's supported for a while :) On all of the above mentioned kernels, I have DRM working, the 3d performance seems to work fine even though I get this message. I had googled it for a while and turned the music up and hoped it would go away ( a car analogy :) ). I'm not sure what they mean/say/recommend on that LKML post or if it is applicable to me or not. ZOK4 I'm interested as well as to your results with a 3.4 kernel as well.

Just an update of the situation... This weekend I had some spare time so I decided to take the challenge and try to compile my very first Lnux kernel. First time I did it i got kernel panic. So after few minutes of going trough my .config file I found out that I didn't check the ext4 file system for compilation (so stupid of me). Yesterday I tried again, and this time everything was fine. No mtrr allocation failed error on the boot. But system hangs when entering runlevel 4 (it can not go to x session). I'm not sure what I did wrong...
The /proc/mtrr file is the same as before:

Code:

$ cat /proc/mtrr

reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back

reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back

reg02: base=0x0a7000000 ( 2672MB), size=  16MB, count=1: uncachable

reg03: base=0x0a8000000 ( 2688MB), size=  128MB, count=1: uncachable

reg04: base=0x0b0000000 ( 2816MB), size=  256MB, count=1: uncachable

reg05: base=0x0ffc00000 ( 4092MB), size=    4MB, count=1: write-protect

reg06: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back

reg07: base=0x140000000 ( 5120MB), size=  256MB, count=1: write-back

reg08: base=0x14fe00000 ( 5374MB), size=    2MB, count=1: uncachable

But there is no mtrr allocation error in the dmesg:

Code:

# dmesg | grep -i mtrr

[    0.000000] MTRR default type: uncachable

[    0.000000] MTRR fixed ranges enabled:

[    0.000000] MTRR variable ranges enabled:

Those 0.000000 are a bit suspicious to me. This means one of two things:
1) Problem is solved
2) I did something wrong in the .config file and the driver doesn't load (thus causing the system hang on entering runlevel 4) - this one is more likely :banghead:

If I manage to figure out what was my mistake I'll let you know.
Best regards! ;)

On my system:

Code:

bash-4.2$ cat /proc/mtrr

reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back

reg01: base=0x07ef00000 ( 2031MB), size=    1MB, count=1: uncachable

reg02: base=0x07f000000 ( 2032MB), size=  16MB, count=1: uncachable

reg03: base=0x080000000 ( 2048MB), size=  256MB, count=1: write-combining

dmesg:

Code:

MTRR default type: uncachable

MTRR fixed ranges enabled:

  00000-9FFFF write-back

  A0000-BFFFF uncachable

  C0000-DFFFF write-protect

  E0000-FFFFF uncachable

MTRR variable ranges enabled:

  0 base 000000000 mask F80000000 write-back

  1 base 07EF00000 mask FFFF00000 uncachable

  2 base 07F000000 mask FFF000000 uncachable

  3 disabled

  4 disabled

  5 disabled

  6 disabled

x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

original variable MTRRs

reg 0, base: 0GB, range: 2GB, type WB

reg 1, base: 2031MB, range: 1MB, type UC

reg 2, base: 2032MB, range: 16MB, type UC

total RAM covered: 2031M

Found optimal setting for mtrr clean up

 gran_size: 64K        chunk_size: 32M        num_reg: 3          lose cover RAM: 0G

New variable MTRRs

reg 0, base: 0GB, range: 2GB, type WB

reg 1, base: 2031MB, range: 1MB, type UC

reg 2, base: 2032MB, range: 16MB, type UC

It would be great if you could post the same section of dmesg.

Hi! Here is the requested part of the dmesg for the default 3.2.29 kernel:

Code:

[    0.000000] MTRR default type: uncachable

[    0.000000] MTRR fixed ranges enabled:

[    0.000000]  00000-9FFFF write-back

[    0.000000]  A0000-BFFFF uncachable

[    0.000000]  C0000-FFFFF write-protect

[    0.000000] MTRR variable ranges enabled:

[    0.000000]  0 base 000000000 mask F80000000 write-back

[    0.000000]  1 base 080000000 mask FC0000000 write-back

[    0.000000]  2 base 0A7000000 mask FFF000000 uncachable

[    0.000000]  3 base 0A8000000 mask FF8000000 uncachable

[    0.000000]  4 base 0B0000000 mask FF0000000 uncachable

[    0.000000]  5 base 0FFC00000 mask FFFC00000 write-protect

[    0.000000]  6 base 100000000 mask FC0000000 write-back

[    0.000000]  7 base 140000000 mask FF0000000 write-back

[    0.000000]  8 base 14FE00000 mask FFFE00000 uncachable

[    0.000000]  9 disabled

[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

[    0.000000] last_pfn = 0xa7000 max_arch_pfn = 0x400000000

[    0.000000] found SMP MP-table at [ffff8800000fe1b0] fe1b0

[    0.000000] initial memory mapped : 0 - 20000000

[    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 20480

[    0.000000] init_memory_mapping: 0000000000000000-00000000a7000000

[    0.000000]  0000000000 - 00a7000000 page 2M

[    0.000000] kernel direct mapping tables up to a7000000 @ 1fffc000-20000000

[    0.000000] init_memory_mapping: 0000000100000000-000000014fe00000

[    0.000000]  0100000000 - 014fe00000 page 2M

[    0.000000] kernel direct mapping tables up to 14fe00000 @ a6e38000-a6e3f000

[    0.000000] ACPI:...

First half is looks like yours but after the x86 PAT part things get funky. Here is the link to the full dmesg for the 3.2.29 kernel.
dmesg for 3.5.4 kernel (which I compiled without i915 module :redface: ):

Code:

[    0.000000] MTRR default type: uncachable

[    0.000000] MTRR fixed ranges enabled:

[    0.000000]  00000-9FFFF write-back

[    0.000000]  A0000-BFFFF uncachable

[    0.000000]  C0000-FFFFF write-protect

[    0.000000] MTRR variable ranges enabled:

[    0.000000]  0 base 000000000 mask F80000000 write-back

[    0.000000]  1 base 080000000 mask FC0000000 write-back

[    0.000000]  2 base 0A7000000 mask FFF000000 uncachable

[    0.000000]  3 base 0A8000000 mask FF8000000 uncachable

[    0.000000]  4 base 0B0000000 mask FF0000000 uncachable

[    0.000000]  5 base 0FFC00000 mask FFFC00000 write-protect

[    0.000000]  6 base 100000000 mask FC0000000 write-back

[    0.000000]  7 base 140000000 mask FF0000000 write-back

[    0.000000]  8 base 14FE00000 mask FFFE00000 uncachable

[    0.000000]  9 disabled

[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

[    0.000000] e820: last_pfn = 0xa7000 max_arch_pfn = 0x400000000

[    0.000000] found SMP MP-table at [mem 0x000fe1b0-0x000fe1bf] mapped at [ffff8800000fe1b0]

[    0.000000] initial memory mapped: [mem 0x00000000-0x1fffffff]

[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576

[    0.000000] init_memory_mapping: [mem 0x00000000-0xa6ffffff]

[    0.000000]  [mem 0x00000000-0xa6ffffff] page 2M

[    0.000000] kernel direct mapping tables up to 0xa6ffffff @ [mem 0x1fac4000-0x1fffffff]

[    0.000000] init_memory_mapping: [mem 0x100000000-0x14fdfffff]

[    0.000000]  [mem 0x100000000-0x14fdfffff] page 2M

[    0.000000] kernel direct mapping tables up to 0x14fdfffff @ [mem 0xa6e38000-0xa6e3efff]

[    0.000000] ACPI:

Those 2 are pretty much the same... And the link to the 3.5.4 full dmesg.

I hope third time Linux kernel compilation will be the charmed one :D
Best regards!

You should set:

MTRR cleanup enable value = 1
MTRR cleanup spare reg num = 1

Maybe it will help.

Quote:

Originally Posted by H_TeXMeX_H (Post 4800351)

You should set:

MTRR cleanup enable value = 1
MTRR cleanup spare reg num = 1

Maybe it will help.

In .conf file? I'll do that! Thank you very much.

Yes, but do it through one of the make options, don't edit the config yourself.