Synopsis
Fix MTRR errors in journal
Background
I began to receive a prompt during boot
You are en rescue mode. after logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue): _
Since I propably messed up something I decided to reinstall the system - a good place to test my recent openbox install media.
It disappeared - but only as long as it took to reboot the system a couple of times.
Finding the cause
Doing the journalctl -xb I found this
jul 15 10:16:35 thinkstation kernel: mtrr_cleanup: can not find optimal value
jul 15 10:16:35 thinkstation kernel: please specify mtrr_gran_size/mtrr_chunk_size
I also found this
mtrr_cleanup: can not find optimal value
please specify mtrr_gran_size/mtrr_chunk_size
MTRR allocation failed. Graphics performance may suffer.
and huge bunch of lines of which only a small portion is listed
jul 15 10:16:35 thinkstation kernel: gran_size: 32M chunk_size: 32M num_reg: 10 lose cover RAM: 126M
jul 15 10:16:35 thinkstation kernel: gran_size: 32M chunk_size: 64M num_reg: 10 lose cover RAM: 30M
jul 15 10:16:35 thinkstation kernel: gran_size: 32M chunk_size: 128M num_reg: 9 lose cover RAM: 30M
jul 15 10:16:35 thinkstation kernel: gran_size: 32M chunk_size: 256M num_reg: 9 lose cover RAM: 30M
jul 15 10:16:35 thinkstation kernel: gran_size: 32M chunk_size: 512M num_reg: 9 lose cover RAM: 30M
jul 15 10:16:35 thinkstation kernel: gran_size: 32M chunk_size: 1G num_reg: 9 lose cover RAM: 30M
jul 15 10:16:35 thinkstation kernel: gran_size: 32M chunk_size: 2G num_reg: 10 lose cover RAM: 30M
Why
After some searching I found that it is Memory Type Range Registers and it is a table telling the system how to cache which ranges of the installed memory.
The drm module tried to get a place to setup a write-combined cache area for the graphics card's memory, but couldn't as all were occupied.
So what now? The source I found to solve this mentions the kernel has options to handle it.
Solution
~ >>> gunzip < /proc/config.gz | grep -i MTRR_SANITIZER
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=0
So it seems that Manjaro ships kernel with the sanitizer option and it is enabled by default so all I had to do was to select a sane value to add to the kernel command line.
The source explained that the listings mentioned above is possible combinations which will use more or less of the available system memory.
Since sanitizer is available and enabled I only have to add the following to the grub command line and rebuild the config.
GRUB_CMDLINE_LINUX="mtrr_gran_size=32M mtrr_chunk_size=128M"
Otherwise it should have been
GRUB_CMDLINE_LINUX="enable_mtrr_cleanup mtrr_spare_reg_nr=0 mtrr_gran_size=32M mtrr_chunk_size=128M"
Rebuilding
sudo grub-mkconfig -o /boot/grub/grub.cfg
Now I have fixed the errors that caused my boot to stop - and I have not those pesky errors in my journal.
And who know I might solve other things like VirtualBox hanging when using 3D acceleration.
Source
http://my-fuzzy-logic.de/blog/index.php?/archives/41-Solving-linux-MTRR-problems.html
