Bug 156637 - no more MTRRs available after startx
Summary: no more MTRRs available after startx
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-02 19:48 UTC by Mark Orenstein
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-02 20:44:02 UTC
Type: ---

Attachments (Terms of Use)
/etc/X11/xorg.conf (2.75 KB, text/plain)
2005-05-02 19:48 UTC, Mark Orenstein
no flags Details

Description Mark Orenstein 2005-05-02 19:48:16 UTC
Description of problem:
The hardware is a Dell Poweredge SC420 using the VESA generic driver.  When 
going into the graphical interface, the message "kernel: mtrr: no more MTRRs 
available" appears in the message log.  

Before startx,

cat /proc/mtrr shows

reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1f800000 ( 504MB), size=   8MB: uncachable, count=1
reg02: base=0x1f700000 ( 503MB), size=   1MB: uncachable, count=1

After startx,

cat /proc/mtrr shows

reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1f800000 ( 504MB), size=   8MB: uncachable, count=1
reg02: base=0x1f700000 ( 503MB), size=   1MB: uncachable, count=1
reg03: base=0xf07a0000 (3847MB), size=  64KB: write-combining, count=1
reg04: base=0xf0780000 (3847MB), size= 128KB: write-combining, count=1
reg05: base=0xf0700000 (3847MB), size= 512KB: write-combining, count=1
reg06: base=0xf0600000 (3846MB), size=   1MB: write-combining, count=1
reg07: base=0xf0400000 (3844MB), size=   2MB: write-combining, count=1

The graphics hardware is

00:02.0 VGA compatible controller: Intel Corp. E7221 Integrated Graphics 
Controller (rev 04) (prog-if 00 [VGA])
	Subsystem: Dell: Unknown device 0180
	Flags: bus master, fast devsel, latency 0, IRQ 169
	Memory at dff80000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at ecd8 [size=8]
	Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Memory at dff40000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: [d0] Power Management version 2

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install FC3 on a Dell Poweredge SC420
2.Boot it up in level 3 followed by startx or in level 5
Actual results:
no more MTRRs

Expected results:
no error messages

Additional info:
I also tried with xorg-X11-6.8.1-12.FC3.21 with the same results.

Comment 1 Mark Orenstein 2005-05-02 19:48:16 UTC
Created attachment 113942 [details]

Comment 2 Mike A. Harris 2005-05-02 20:44:02 UTC
MTRRs are a finite limited resource provided by the CPU (for CPUs that
support MTRRs).  The BIOS may use some of these to set cacheability
of memory regious during POST, and the OS can modify/add/remove
regions after that.  However, the OS is limited to using what the
hardware provides.

Additionally, MTRRs have CPU specific rules for how they must be set up.
In general, they must be a size range that is a power of 2, and be on
a boundary that is a multiple of the size range.  The exact rules are
CPU brand and model specific.  On systems with lots of free MTRRs,
often a single MTRR can be used to cover the video framebuffer.  Some
systems however the video framebuffer does not show up in the memory
map at an optimal location, and in order to obey the hardware rules,
the X server has to divide the framebuffer region into multiple
ranges, each of which obey the rules for setting MTRRs.  In some cases,
this requires using many MTRRs, and depending on how many were used
by the system to begin with, it may result in the inability to set
MTRRs for the entire framebuffer.

This is not a software bug or limitation however.  It is a hardware
limitation of the system in question.  If the video hardware is not
on-board, you can try switching it to a different slot if possible
(PCI or PCI-E), which sometimes causes the framebuffer to get assigned
a different memory address which might have more favourable MTRR
math, and require fewer entries.  This is not the case for onboard
video such as Intel integrated however as you can not change the

MTRRs were a CPU hack added onto Intel CPUs a long time ago, and there
are some rather serious limitations in the hardware that can not be
worked around in software.  This is becoming more and more of a problem
on newer systems, in particular with video hardware that has non-contiguous
memory, as multiple MTRRs *must* be used on them.

Unfortunately, there is no solution for this hardware problem at this
time, because Xorg, XFree86, and the Linux kernel are limited to using
MTRR, as that is the only mechanism provided for setting cacheability
of memory regions.

Since Pentium Pro and later, and Athlon and later however, the CPUs
provide an alternate and superior mechanism in hardware to allow
software to set the cacheability of memory on a page-granular basis.
This is the Intel "PAT" (Page Attribute Table) feature.  Processors
that show "pat" in flags in /proc/cpuinfo have this capability in
hardware.  Unfortunately, Linux does not implement PAT feature support
at this point in time, and so the X server is unable to use it, and
is limited then to using the MTRR feature, with it's inherent

Once someone finishes off Linux PAT support, and gets it integrated
into Linus's kernel, it will be easy to add support to Xorg to use
PAT instead of MTRR, and this problem will more or less vanish.  Until
that time however, the X server is limited to the features the hardware
provides, and that means that it is unable to set up write-combining
on some hardware out there due to MTRR limitations.

You might try decreasing or increasing the amount of system memory
allocated to video memory in your BIOS, as this may alter the way
memory gets assigned, and how many MTRRs might be needed.  Other than
that, there is no other workaround until PAT support is included in
the Linux kernel.

Setting status to NOTABUG (hardware limitation).

Note You need to log in before you can comment on or make changes to this bug.