Read /proc/mtrr Without Breaking Cache Settings

An old forum post tells you to write a range straight into /proc/mtrr to fix a sluggish display. One wrong base address quietly recaches the wrong slice of physical memory. This guide checks whether the legacy interface even exists on this kernel, reads its entries safely, and shows when to stop instead of forcing a workaround built for a different decade. Allow about ten minutes.

You need a shell; the inspection commands are unprivileged, though a restricted container may hide the file even when the host kernel supports MTRRs. This follows the installed proc_mtrr(5) page from Linux man-pages 6.7, dated 15 August 2023, and the upstream Linux x86 documentation. The test system runs kernel 6.8.0-139-generic. MTRR is an x86 facility, so none of this applies to other architectures.

1. Check whether the interface exists

Start with a read-only test. Do not use sudo yet, and do not redirect anything into the file.

$ test -r /proc/mtrr && echo '/proc/mtrr is readable' || echo '/proc/mtrr is unavailable or unreadable'

A readable result means this process can inspect the legacy interface. A failure is not proof the CPU lacks MTRRs: the kernel may have been built without the support, the interface may be absent on this kernel, or a container policy may be hiding it. Check the environment before treating the result as a hardware diagnosis.

$ uname -r
6.8.0-139-generic
$ stat /proc/mtrr

Your version and stat output will differ. If stat reports the path does not exist, stop here: there is no useful MTRR configuration to perform through this path.

2. Read the current ranges

If the file is readable, display it with cat:

$ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size= 256MB: write-back, count=1

Each line is a register slot: a physical base address, a byte size in a human-readable unit, a memory type, and a reference count. Common types include write-back, write-combining, and uncachable. Treat the output as a report of the kernel's current view, not a list of ranges to recreate by hand.

On a system with no configured variable ranges, output may be empty. On this host, /proc/mtrr is not readable from the current process, so there is no local register listing to copy. That is an access result, not a reason to write a guessed range.

3. Understand the legacy write interface

The upstream MTRR documentation describes an ASCII administration interface as well as an ioctl interface for programs. Adding a new range looks like this:

# printf '%s\n' 'base=0xf8000000 size=0x400000 type=write-combining' > /proc/mtrr

Removing a slot looks like this:

# printf '%s\n' 'disable=2' > /proc/mtrr

Before considering a change, take a complete copy of the current output and identify the device documentation that requires it:

$ cat /proc/mtrr | tee "$HOME/mtrr-before.txt"
$ dmesg | grep -i mtrr

The first command changes no kernel state but writes a record in your home directory. The second may need elevated access on a hardened system. If you cannot explain why a specific device needs a legacy MTRR range, do not proceed.

4. Prefer PAT-aware interfaces for new work

• Modern x86 Linux uses PAT, not MTRR. The Page Attribute Table has taken over from direct MTRR manipulation, and the kernel documentation says direct MTRR use by drivers has been phased out.
• Driver code has its own interfaces. ioremap_wc() for device mappings, or the appropriate set_memory_* helpers for RAM ranges. Those are kernel programming interfaces, not shell commands for changing an arbitrary machine.
• Do not port old forum commands forward. Finding a command that writes to /proc/mtrr and applying it to a current graphics stack is the classic mistake. For a display or PCI performance problem, start with the device driver's current documentation and its logs instead.

5. Recover from an investigated change

If an administrator has already changed a range, compare the current listing with the saved record:

$ diff -u "$HOME/mtrr-before.txt" <(cat /proc/mtrr)

Undoing a change is not a generic "reset" command. It needs the changed register identified and a device-specific configuration to replace it. Use the documented disable=<register> form only once you have confirmed the slot number and have an explicit recovery plan. If a graphical or device service is affected, stop and use its vendor or distribution recovery procedure rather than experimenting with overlapping ranges.