Kernel: e820/MTRR huge-page mapping error

zpg443 · 2016-12-20 21:29:53

This error message is reported in particular by those with Haswell processors:

Dec 20 13:43:50 archmain kernel: pmd_set_huge: Cannot satisfy [mem 0xf8000000-0xf8200000] with a huge-page mapping due to MTRR override.

It has to do with how the kernel maps the info provided by the bios' memory map (e820) to create the RAMDISK, source reference is init.c:

http://lxr.free-electrons.com/source/ar … nit.c#L409

In my case, the kernel (4.8.13-1) finds the SMP MP-table correctly, but the kernel scans the area for low memory corruption:

Dec 20 13:43:50 archmain kernel: x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
Dec 20 13:43:50 archmain kernel: e820: update [mem 0xcf000000-0xffffffff] usable ==> reserved
Dec 20 13:43:50 archmain kernel: e820: last_pfn = 0xce000 max_arch_pfn = 0x400000000
Dec 20 13:43:50 archmain kernel: found SMP MP-table at [mem 0x000fd100-0x000fd10f] mapped at [ffff8800000fd100]
Dec 20 13:43:50 archmain kernel: Scanning 1 areas for low memory corruption

The kernel sucessfully boots the SMP configuration anyway, even though init.c did not build the RAMDISK with the huge-page mapping. My Debian 8.6 partition processed huge-pages correctly and did not find any issue with low-level memory:

Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0x00000000-0x000fffff]
Dec 20 11:23:04 debianmain kernel:  [mem 0x00000000-0x000fffff] page 4k
Dec 20 11:23:04 debianmain kernel: BRK [0x01cf4000, 0x01cf4fff] PGTABLE
Dec 20 11:23:04 debianmain kernel: BRK [0x01cf5000, 0x01cf5fff] PGTABLE
Dec 20 11:23:04 debianmain kernel: BRK [0x01cf6000, 0x01cf6fff] PGTABLE
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0x21fc00000-0x21fdfffff]
Dec 20 11:23:04 debianmain kernel:  [mem 0x21fc00000-0x21fdfffff] page 2M
Dec 20 11:23:04 debianmain kernel: BRK [0x01cf7000, 0x01cf7fff] PGTABLE
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0x21c000000-0x21fbfffff]
Dec 20 11:23:04 debianmain kernel:  [mem 0x21c000000-0x21fbfffff] page 2M
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0x200000000-0x21bffffff]
Dec 20 11:23:04 debianmain kernel:  [mem 0x200000000-0x21bffffff] page 2M
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0x00100000-0xbb0eafff]
Dec 20 11:23:04 debianmain kernel:  [mem 0x00100000-0x001fffff] page 4k
Dec 20 11:23:04 debianmain kernel:  [mem 0x00200000-0x3fffffff] page 2M
Dec 20 11:23:04 debianmain kernel:  [mem 0x40000000-0x7fffffff] page 1G
Dec 20 11:23:04 debianmain kernel:  [mem 0x80000000-0xbaffffff] page 2M
Dec 20 11:23:04 debianmain kernel:  [mem 0xbb000000-0xbb0eafff] page 4k
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0xbb0f2000-0xbbd14fff]
Dec 20 11:23:04 debianmain kernel:  [mem 0xbb0f2000-0xbb1fffff] page 4k
Dec 20 11:23:04 debianmain kernel:  [mem 0xbb200000-0xbbbfffff] page 2M
Dec 20 11:23:04 debianmain kernel:  [mem 0xbbc00000-0xbbd14fff] page 4k
Dec 20 11:23:04 debianmain kernel: BRK [0x01cf8000, 0x01cf8fff] PGTABLE
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0xbc1ab000-0xcd4a2fff]
Dec 20 11:23:04 debianmain kernel:  [mem 0xbc1ab000-0xbc1fffff] page 4k
Dec 20 11:23:04 debianmain kernel:  [mem 0xbc200000-0xcd3fffff] page 2M
Dec 20 11:23:04 debianmain kernel:  [mem 0xcd400000-0xcd4a2fff] page 4k
Dec 20 11:23:04 debianmain kernel: BRK [0x01cf9000, 0x01cf9fff] PGTABLE
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0xcd4f5000-0xcd53afff]
Dec 20 11:23:04 debianmain kernel:  [mem 0xcd4f5000-0xcd53afff] page 4k
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0xcdfff000-0xcdffffff]
Dec 20 11:23:04 debianmain kernel:  [mem 0xcdfff000-0xcdffffff] page 4k
Dec 20 11:23:04 debianmain kernel: init_memory_mapping: [mem 0x100000000-0x1ffffffff]
Dec 20 11:23:04 debianmain kernel:  [mem 0x100000000-0x1ffffffff] page 1G
Dec 20 11:23:04 debianmain kernel: RAMDISK: [mem 0x36342000-0x37198fff]

Arch reported this section differently:

Dec 20 14:47:00 archmain kernel: BRK [0x02d4d000, 0x02d4dfff] PGTABLE
Dec 20 14:47:00 archmain kernel: BRK [0x02d4e000, 0x02d4efff] PGTABLE
Dec 20 14:47:00 archmain kernel: BRK [0x02d4f000, 0x02d4ffff] PGTABLE
Dec 20 14:47:00 archmain kernel: BRK [0x02d50000, 0x02d50fff] PGTABLE
Dec 20 14:47:00 archmain kernel: BRK [0x02d51000, 0x02d51fff] PGTABLE
Dec 20 14:47:00 archmain kernel: BRK [0x02d52000, 0x02d52fff] PGTABLE
Dec 20 14:47:00 archmain kernel: RAMDISK: [mem 0x374b4000-0x37a51fff]

The RAMDISK was not mapped to the same address based on MTTR override, thus generating the error:

Dec 20 13:43:50 archmain kernel: pmd_set_huge: Cannot satisfy [mem 0xf8000000-0xf8200000] with a huge-page mapping due to MTRR override.

According to this discussion, overlapping entries of write-back memory (MTRR) is safe:

MTRRs have the default memory type, which is used when the given range
is not covered by any MTRR entries. There are two types of BIOS setup:
1) Default UC
- BIOS sets the default type to UC, and covers all WB accessible ranges
with MTRR entries of WB.
2) Default WB
- BIOS sets the default type to WB, and covers non-WB accessible range
with MTRR entries of other memory types, such as UC.
In both cases, WB type can be returned. In case of 1), the requested
range may overlap with multiple MTRR entries of WB type, which is still
safe.

So, this error does not appear to create a fatal performance issue (that I can find) or cause a crash, and I am ignoring it. If anyone knows how to make RAMDISK mapping work cleaner or can help this newbie understand better, please advise.

Last edited by zpg443 (2016-12-20 21:31:04)

damianatorrpm · 2018-02-15 12:34:58

https://lwn.net/Articles/635357/
use kernel option "nohugeiomap"

R00KIE · 2018-02-15 14:18:54

Please don't necro-bump threads. Closing.

https://wiki.archlinux.org/index.php/Co … bumping.22

Arch Linux

#1 2016-12-20 21:29:53

Kernel: e820/MTRR huge-page mapping error

#2 2018-02-15 12:34:58

Re: Kernel: e820/MTRR huge-page mapping error

#3 2018-02-15 14:18:54

Re: Kernel: e820/MTRR huge-page mapping error

Board footer