Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa()

[Yinghai Lu]

On Tue, Jul 15, 2014 at 1:33 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
> [+cc Yinghai, Rafael]
>

>>> http://pastebin.com/FiL7N64b
>>
>> I opened this bugzilla:
>> https://bugzilla.kernel.org/show_bug.cgi?id=80041 and attached your
>> dmesg to it.  I see what the problem is, but I don't have a good idea
>> yet for how to fix it.
>>
>> 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
>
> One of the reasons for iomem_resource is so we don't hand out the same
> address space to two different devices.  We *could* do that by keeping
> track of the union of all devices and reserved areas that we know
> about.
>
> But the current resource code is more strict: it enforces a hierarchy.
> For example, in this case, it rejects the 00:00 PNP resource because
> it is larger than the e820 entry.  The problem with rejecting it is
> that we might hand out [mem 0xfed14000-0xfed17fff] to another device
> even though PNP told us that it's in use.
>
> I'm about to head out for a few weeks of vacation, so I won't be able
> to do anything with this.

In that case, we could reserve the whole MCH range in e820 from
trim_snb_memory() instead.

HPA, what is your idea about it?

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/