# mtrr trouble

## alex.blackbit

hi,

ATTENTION, long post

i have problems with mtrr. my system "works", but the graphics performance is extremely bad.

in the bios there is a switch i can toggle: "discrete mtrr allocation" with the description  *Quote:*   

> this feature is used to configure the mtrr method. disabling the feature will set the mtrr method in continuous status.

 

i tried both and get following results. switched off

```
# cat /proc/mtrr 

reg00: base=0xc0000000 (3072MB), size=197632MB: uncachable, count=1

reg01: base=0x00000000 (   0MB), size=200704MB: write-back, count=1

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

#
```

switched on

```
# cat /proc/mtrr

reg00: base=0x00000000 (   0MB), size=198656MB: write-back, count=1

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

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

#
```

anyway i get these messages in dmesg:

```
# dmesg|grep mtrr

Command line: root=/dev/sda1 video=uvesafb:1280x1024-24@97,mtrr:3,ywrap

Kernel command line: root=/dev/sda1 video=uvesafb:1280x1024-24@97,mtrr:3,ywrap

mtrr: type mismatch for d8000000,800000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,400000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,200000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,100000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,80000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,40000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,20000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,10000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,8000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,4000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,2000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,1000 old: write-back new: write-combining

mtrr: type mismatch for d8000000,2000000 old: write-back new: write-combining

#
```

the last line appears after the start of X.

in the logs of X i get:

```
# grep -E "(^\(WW\)|^\(EE\)|^\(NI\)|^\(??\))" /var/log/Xorg.0.log

(WW) VESA(0): Failed to set up write-combining range (0xd8000000,0x2000000)

#
```

all of this results in extremely poor graphics performance. uvesafb is actually working with a resolution of 1280x1024, but on the console a dmesg takes 3-5 seconds to scroll down.

```
# dmesg | grep uvesafb

Command line: root=/dev/sda1 video=uvesafb:1280x1024-24@97,mtrr:3,ywrap

Kernel command line: root=/dev/sda1 video=uvesafb:1280x1024-24@97,mtrr:3,ywrap

uvesafb: XGI Technology, Inc., Volari Z9s, 1.09.10, OEM: XGI, VBE v3.0

uvesafb: VBIOS/hardware supports DDC2 transfers

uvesafb: monitor limits: vf = 97 Hz, hf = 129 kHz, clk = 364 MHz

uvesafb: scrolling: redraw

uvesafb: framebuffer at 0xd8000000, mapped to 0xffffc20003100000, using 10240k, total 32768k

#
```

in X there is not much to expect since i only have a xvi volari z7, but the results would definitely be better when the mtrr would be correct.

searching on the inet i found this.

so i thought i should try with the following:

disable 0,1,2 (since cat /proc/mtrr shows these ranges).

set write-back beginning at 0 size 4gig (100000000 in hex) for system ram.

set write-combining beginning at 0d8000000 size 32meg (002000000 in hex) for video ram. (i took the begin of this memory range from the dmesg output)

```
echo "disable=0" >| /proc/mtrr

echo "disable=1" >| /proc/mtrr

echo "disable=2" >| /proc/mtrr

echo "base=0x0 size=0x100000000 type=write-back" >| /proc/mtrr

echo "base=0xd8000000 size=0x2000000 type=write-combining" >| /proc/mtrr
```

but this gives me "invalid argument on the last command, apparently because the memory range i try to assign overlaps the previously defined one.

since 0xd8000000 is 3456meg and i have 2x2gig ram in my machine i removed on of the ram sticks and rebooted. the video ram memory range still started at 0xd8000000. i did

```
echo "base=0x0 size=0x80000000 type=write-back" >| /proc/mtrr

echo "base=0xd8000000 size=0x2000000 type=write-combining" >| /proc/mtrr
```

that succeeded. now i started X, and voilà! no error messages, neither in dmesg, nor in X log and at least 1500 fps in glxgears. console performance is still poor, because the right values came after initializing the uvesafb stuff.

so, what can i do now? OF COURSE I DO WANT to keep my 4gig ram. btw the board can hold up to 64gig.

is this a bug in the bios?

oh, i forgot to mention: the memory ranges i get from the bios are with bios version 1.03. before i had 1.01 with different results. even more ranges with even more idiotic values.

this is the latest version.

can anybody tell if this is a problem i can fix or if is has to be fixed by the mainboard vendor with a new bios revision?

i know this is a long post. hopefully someone took the time to read it and has a idea.

thanks, alex

----------

## CooSee

please try  ' mtrr:2 '  :Exclamation: 

```
root=/dev/sda1 video=uvesafb:1280x1024-24@97,mtrr:3,ywrap
```

EDIT: from Kernel Documentation '  /usr/src/linux/Documentation/fb/uvesafb.txt '  :Exclamation: 

```
If you see the following in dmesg, choose the type that matches

        the old one.  In this example, use "mtrr:2".

...

mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
```

CooSee ' Ya

----------

## alex.blackbit

i had this setting when i started to find out why the performance is so poor.

this does not solve the problem that the subsystems which need to access the graphics adapter do get the wrong memory range.

thanks for the answer anyway.

----------

## Pysen

I remap my MTRR in a startup script every boot.

Here are some rules for remapping (fetched from http://www.rage3d.com/board/showthread.php?t=33821469).

 *Quote:*   

> - Your system's memory consists of normal physical 'main' memory, as well as memory address ranges used for talking to your devices.
> 
> - A section of 'main' memory is used for your AGP aperature... which the video card uses as additional video memory. It actually can use more system memory than that, but can only directly access the aperature memory on it's own... other data must be swapped/paged in and out of the aperature space by your CPU.
> 
> - Your video driver will attempt to use one or more "write-combining" MTRR region entries for talking to the AGP aperature and it's video memory. It will attempt to create write-combining MTRR region entries if they don't already exist (creates them on X startup, removes them on shutdown).
> ...

 

----------

## NeddySeagoon

alex.blackbit,

```
(WW) VESA(0): ...
```

 That snippet says you are using the vesa driver in Xorg.

Its not related to framebuffer and provides no accelerated features at all.

The only reason to use the vesa driver is because no other one (except VGA) works with your GPU.

----------

