The kconfig option VAR_MTRR_HOLE prevents some linux kernel versions from making the video frame buffer write combining when 4GB or more DRAM is used. These linux kernel versions add a WC variable MTRR range to make the video frame buffer write combining. With VAR_MTRR_HOLE disabled, it works as expected:
cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xe0000000 (3584MB), size= 16MB: write-combining, count=1 (linux added the third range)
When VAR_MTRR_HOLE is enabled, linux does not add the WC range, and logs a warning message:
cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 dmesg mtrr: type mismatch for e0000000,1000000 old: write-back new: write-combining
The reason it fails in the second example is that linux knows memory covered by a variable MTRR range of type UC cannot be changed to a different type by overlapping a new MTRR range. For this reason, VAR_MTRR_HOLE should be not be used. The justification for the VAR_MTRR_HOLE method is to conserve variable MTRR pairs. There are other ways to conserve MTRR ranges. For example, AMD systems can use Tom2ForceMemTypeWB to avoid the need for MTRR ranges above 4GB. Intel systems could sacrifice a small abount of DRAM when very small holes cause excessive MTRR consumption.
Here is a non-coreboot example of the same problem: https://bugs.launchpad.net/linux/+bug/210780
I am thinking that once the AMD Tom2ForceMemTypeWB support is in place, we should switch the default for AMD systems so that this linux write combining problem can be avoided.
Thanks, Scott