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): xorg-X11-6.8.2-1.FC3.13 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 3. 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.
Created attachment 113942 [details] /etc/X11/xorg.conf
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 slot. 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 limitations. 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).