# [workaround] MTRR allocation failed.  [...]

## equaeghe

Hi,

I have a Sandy Bridge ThinkPad X220 with 8GB of ram and use the i915 graphics driver. [EDIT: I enable KMS, which is working.]

While perusing my logs, I encountered:

```

# grep MTRR /var/log/everything/current

[kernel] [    0.768627] mtrr: no more MTRRs available

[kernel] [    0.768728] [drm] MTRR allocation failed.  Graphics performance may suffer.

```

[EDIT: With dmesg, I additionally find:

```

[    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 0FFC00000 mask FFFC00000 write-protect

[    0.000000]   1 base 000000000 mask F80000000 write-back

[    0.000000]   2 base 080000000 mask FC0000000 write-back

[    0.000000]   3 base 0C0000000 mask FE0000000 write-back

[    0.000000]   4 base 0DC000000 mask FFC000000 uncachable

[    0.000000]   5 base 0DB000000 mask FFF000000 uncachable

[    0.000000]   6 base 100000000 mask F00000000 write-back

[    0.000000]   7 base 200000000 mask FE0000000 write-back

[    0.000000]   8 base 21F000000 mask FFF000000 uncachable

[    0.000000]   9 base 21E800000 mask FFF800000 uncachable

```

]

Looking at the MTRR's, I got:

```

# cat /proc/mtrr                                                                                                                         

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

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

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

reg03: base=0x0c0000000 ( 3072MB), size=  512MB, count=1: write-back

reg04: base=0x0dc000000 ( 3520MB), size=   64MB, count=1: uncachable

reg05: base=0x0db000000 ( 3504MB), size=   16MB, count=1: uncachable

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

reg07: base=0x200000000 ( 8192MB), size=  512MB, count=1: write-back

reg08: base=0x21f000000 ( 8688MB), size=   16MB, count=1: uncachable

reg09: base=0x21e800000 ( 8680MB), size=    8MB, count=1: uncachable

```

I don't know how to interpret/work with this, but it does look rather messy; in other forums, the number of MTRRs goes up to at most 8.

From other forum posts, I gathered that the kernel can be configured to clean up MTRRs, but this is already done:

```

# grep MTRR /usr/src/linux/.config

CONFIG_MTRR=y

CONFIG_MTRR_SANITIZER=y

CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1

CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

# grep X86_PAT /usr/src/linux/.config

CONFIG_X86_PAT=y

```

What further steps can I take? Is further diagnosis needed.

(The laptop is working fine, but if I can get better graphics performance, I would of course like to.)

N.B.: The only other non-successful graphics-related message in my logs is:

```

# grep "AGP bridge" /var/log/everything/current

Jan 24 08:47:36 [kernel] [    0.000000] No AGP bridge found

Jan 24 08:47:36 [kernel] [    0.000000] No AGP bridge found

```

EDIT:

 I tried the suggestion at http://forum.notebookreview.com/lenovo-ibm/575569-linux-x220-20.html#post7811297 but it did not work.

 Red hat bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=584493

Last edited by equaeghe on Fri Feb 17, 2012 10:00 pm; edited 4 times in total

----------

## aCOSwt

Did you request write-combining (mtrr:3) as part of your boot command line ?

(I use lilo and set this line : 

```
append="video=vesafb:mtrr:3,ywrap"
```

)

----------

## equaeghe

 *aCOSwt wrote:*   

> Did you request write-combining (mtrr:3) as part of your boot command line ?
> 
> 

 

No, I use KMS, which requires no fb driver, so I don't use vesafb.

----------

## Gusar

Ignore the message. If your processor has PAT (and it probably does), it'll be used instead of MTRR.

If you want to give it a test, boot with nopat on the kernel line in grub.conf.

----------

## equaeghe

 *Gusar wrote:*   

> Ignore the message. If your processor has PAT (and it probably does), it'll be used instead of MTRR.

 

PAT is enabled on my system, however, as far as I've understood, MTRR stuff needs to be in order anyway.

My understanding is based on:

From http://en.gentoo-wiki.com/wiki/MTRR:

 *Quote:*   

> 
> 
> PAT Support Is a new type of memory type register which works with MTRR it works NOT as a MTRR but instead allows faster more flexible way in partitioning memory resources. Note PAT does not allocate the memory resources like MTRR does but takes control of the memory inside of what the MTRR has allocated. A fair statement would be to say for a system supporting MTRR and PAT would be: MTRR creates the memory mapping and PAT manages the tables inside of them. 
> 
> 

 

From /usr/src/linux/Documentation/x86/pat.txt:

 *Quote:*   

> 
> 
> x86 Page Attribute Table (PAT) allows for setting the memory attribute at the
> 
> page level granularity. PAT is complementary to the MTRR settings which allows
> ...

 

----------

## Gusar

Did you do the test with nopat? I did once on my netbook. After I saw the results, I stopped caring that I have messed up MTRRs.

----------

## equaeghe

 *Gusar wrote:*   

> Did you do the test with nopat? I did once on my netbook. After I saw the results, I stopped caring that I have messed up MTRRs.

 

Yes, I am currently running with nopat. There is no noticeable difference in speed/graphics responsiveness.

I will report back if I do notice a difference.

Perhaps this means PAT has no (beneficial) effect on my system because my MTRRs are not set up as they should.

----------

## Gusar

 *equaeghe wrote:*   

> Perhaps this means PAT has no (beneficial) effect on my system because my MTRRs are not set up as they should.

 

Or perhaps it means that despite screwed up MTRRs, they're still good enough? Do you actually notice any issues, or did you just see the error message?

----------

## equaeghe

 *Gusar wrote:*   

> Do you actually notice any issues, or did you just see the error message?

 

My graphics is stable; speed/responsiveness seems decent when comparing to a 6 year old laptop.

The error message is quite clear:

 *Quote:*   

> 
> 
> # grep MTRR /var/log/everything/current
> 
> [kernel] [    0.768627] mtrr: no more MTRRs available
> ...

 

drm tries to allocate an MTRR for the benefit of the graphics subsystem, but it can't, which has an unknown impact on the graphics performance.

The only way I am able to judge whether this impact is important or not is to fix my MTRR setup and make the comparison. As your experience with PAT showed, these setting may have an important impact. Currently, assuming that I will gain nothing by fixing my MTRR setup is just speculation.

----------

## equaeghe

The following workaround is available:

https://lkml.org/lkml/2011/9/9/424

* build drm as a module and not in the kernel (unimportant esthetical downside: nice framebuffer second or two later in the booting process)

* disable the MTRR write-protect entry that currently precludes automatic MTRR rewriting right before loading the drm module; i.e., in /etc/modprobe.d/drm.conf put (in my case):

```
install drm (echo "disable=0" > /proc/mtrr); /sbin/modprobe --ignore-install drm $CMDLINE_OPTS

```

Perhaps the MTRR cleanup routine will be able to deal with write-protect entries in the future...

----------

