Created attachment 142741 [details]
dmesg

Fabio Coatti reported this warning in v3.15.5:

resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff reserved

The warning is from snb_uncore_imc_init_box(), and Fabio bisected it to b9e1ab6d4c05 ("perf/x86/uncore: add SNB/IVB/HSW client uncore memory controller support"), which added snb_uncore_imc_init_box().

This doesn't occur on v3.14, so in that sense it's a regression.  But there's nothing wrong with b9e1ab6d4c05; it's requesting the correct area ([mem 0xfed10000-0xfed15fff]).

The problem is that we don't handle e820 and PNP device resource information correctly.  From the attached dmesg, we have this:

  BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
  system 00:00: [mem 0xfed10000-0xfed17fff] could not be reserved

The 00:00 PNP device describes the correct 32K range for the Intel MCH (see [1] for details).  But the [mem 0xfed10000-0xfed13fff] entry from e820 was added to the resource map first, and it covers only the first 16K of the MCH range.  This caused the subsequent PNP reservation to fail.  Then the snb_uncore_imc_init_box() reservation caused the warning, because it would be a child of the e820 entry but it covers more space.

[1] fixed a similar issue where the PNP device described only the first 16K of the MCH range.  This case is slightly different because here it's the e820 entry that is incorrect.

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb171f7abb9a