mtrr_cleanup: can not find optimal value, perhaps no longer needed?

[Bryan Quigley]

The actual common error message from dmesg:

[ 0.000000] original variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 32GB, type WB
[ 0.000000] reg 1, base: 3584MB, range: 512MB, type UC
[ 0.000000] reg 2, base: 3548MB, range: 4MB, type UC
[ 0.000000] reg 3, base: 3552MB, range: 32MB, type UC
[ 0.000000] total RAM covered: 32220M
[ 0.000000] gran_size: 64K chunk_size: 64K num_reg: 7 lose cover RAM: 28676M
[ 0.000000] gran_size: 64K chunk_size: 128K num_reg: 7 lose cover RAM: 28676M
[ 0.000000] gran_size: 64K chunk_size: 256K num_reg: 7 lose cover RAM: 28676M
[ 0.000000] gran_size: 64K chunk_size: 512K num_reg: 7 lose cover RAM: 28676M
[ 0.000000] gran_size: 64K chunk_size: 1M num_reg: 7 lose cover RAM: 28676M
...
[ 0.000000] gran_size: 256M chunk_size: 2G num_reg: 6 lose cover RAM: 220M
[ 0.000000] gran_size: 512M chunk_size: 512M num_reg: 5 lose cover RAM: 476M
[ 0.000000] gran_size: 512M chunk_size: 1G num_reg: 5 lose cover RAM: 476M
[ 0.000000] gran_size: 512M chunk_size: 2G num_reg: 5 lose cover RAM: 476M
[ 0.000000] gran_size: 1G chunk_size: 1G num_reg: 5 lose cover RAM: 476M
[ 0.000000] gran_size: 1G chunk_size: 2G num_reg: 5 lose cover RAM: 476M
[ 0.000000] gran_size: 2G chunk_size: 2G num_reg: 4 lose cover RAM: 1500M
[ 0.000000] mtrr_cleanup: can not find optimal value
[ 0.000000] please specify mtrr_gran_size/mtrr_chunk_size

I have found errors like this on many machines (one with 128 GB of RAM, mine with just 4GB). The instructions want you to specify kernel options that you don't need to do. Just turning off mtrr_cleanup appears to be the best option. You can fix it be specifying disable_mtrr_cleanup.

According to kernel paramaters (https://www.kernel.org/doc/Documentation/kernel-parameters.txt)

 disable_mtrr_cleanup [X86]
   The kernel tries to adjust MTRR layout from continuous
   to discrete, to make X server driver able to add WB
   entry later. This parameter disables that.

From this I understand it was here to help allow leave the X server space if it needed it in the future. That should no longer be necessary, correct? I have an Intel GPU and noticed no performance problems by disabling it.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image-3.8.0-16-generic 3.8.0-16.26
ProcVersionSignature: Ubuntu 3.8.0-16.26-generic 3.8.5
Uname: Linux 3.8.0-16-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.9.2-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: bryan 1978 F.... pulseaudio
Date: Tue Apr 2 16:56:13 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-02-04 (56 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130204.1)
MachineType: Dell Inc. Inspiron 1545
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-16-generic root=UUID=0983e077-6f15-4e52-a776-faa186229dc8 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.8.0-16-generic N/A
 linux-backports-modules-3.8.0-16-generic N/A
 linux-firmware 1.104
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/07/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A14
dmi.board.name: 0G848F
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA14:bd12/07/2009:svnDellInc.:pnInspiron1545:pvr:rvnDellInc.:rn0G848F:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Inspiron 1545
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.9 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc5-raring/

[Bryan Quigley (bryanquigley)]

Marked it as kernel-bug-exists-upstream, but I should point out that it could be "fixed" by simply disabling mtrr_cleanup in the kernel build (so it might be an Ubuntu config choice?).

[Andy Whitcroft (apw)]

This was enabled because many machines do not have spance for an MTRR for the AGP Gart space. Without one we are unable to switch the graphics display memory into Write Combining mode with a serious performance hit. The errors in your case seem to be benign as I assume you have sufficient space to make this entry anyway. The errors are simply reported to the kernel log and for most people this is not seen, I do not believe they would be given any popup or asked to file a bug. Given the upsides for those affected by the lack of space, I think this is a positive option in the main.

[Bryan Quigley (bryanquigley)]

Is there a good way to identify a machine that is helped by having this on? I'm curious as to what kind of hardware requires mtrr_cleanup to perform well.

The 128 GB RAM Machine, did result in some RAM lost, but it wasn't significant considering it has 128 GB of RAM (around 128 MB loss if memory serves me). If this improves graphical performance significantly for many machines, it's probably worth the loss for machines with huge amounts of RAM.

Does switching the graphics memory to Write Combining originate in KMS now (instead of Xorg)?

[Bryan Quigley (bryanquigley)]

It seems MTRR support is being deprecated now - http://lkml.iu.edu/hypermail/linux/kernel/1508.3/04830.html, commit 2baa891e42d84159b693eadd44f6fe1486285bdc.

Perhaps disabling MTRR (as opposed to just mtrr_cleanup) might be considered for xenial? I believe it may affect boot time when the cleanup is ran.

[Bryan Quigley (bryanquigley)]

My testing could not find any difference in boot time using systemd's tools.

[Bryan Quigley (bryanquigley)]

From my latest testing, we do currently support machines that don't have PAT support (really old 32 bit x86). So this can be revisited at some future point when we go 64 bit only for x86.

[RavanH (ravanhagen)]

OK, 7 years after the original report, this issue still seems relevant on Ubuntu 20.04.

So how to know if a machine needs mtrr_cleanup at all?

[Tom Reynolds (tomreyn)]

It is my impression that specifying "mtrr_gran_size/mtrr_chunk_size" when "mtrr_cleanup: can not find optimal value" is still useful on some systems.
The latest system where I helped identifying good values (according to https://github.com/tomreyn/linux_mtrr_size_fix) was a
  Gigabyte Z97X-Gaming 3, BIOS F7 09/18/2015
with
  Intel i5-4690K (incl. GPU)
and
  some dedicated Nvidia graphics chipset
running
  Linux version 5.4.0-40-generic (buildd@lcy01-amd64-011) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 (Ubuntu 5.4.0-40.44-generic 5.4.44)
and Nvidia proprietary driver 440.100:
https://paste.ubuntu.com/p/VqnhtHmWd4/

Setting specific mtrr_gran_size/mtrr_chunk_size values actually helped the user get reliable graphics on Xorg on this Ubuntu 18.04 (+LTSE stack) system.

So it does still seem relevant at times.

[Bryan Quigley (bryanquigley)]

Closing this per above comment. Thanks. It still seems eventually that MTRR might be drop-able, but won't just leave this open waiting for future.