Bug 80041 - Resource sanity check warning (Intel MCH on HP Folio 9470m)
Summary: Resource sanity check warning (Intel MCH on HP Folio 9470m)
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: PCI (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_pci@kernel-bugs.osdl.org
URL: http://lkml.kernel.org/r/201407072047...
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-11 18:06 UTC by Bjorn Helgaas
Modified: 2014-07-11 19:42 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.15
Tree: Mainline
Regression: No


Attachments
dmesg (49.04 KB, text/plain)
2014-07-11 18:06 UTC, Bjorn Helgaas
Details

Description Bjorn Helgaas 2014-07-11 18:06:37 UTC
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

Note You need to log in before you can comment on or make changes to this bug.