Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa()
From: H. Peter Anvin
Date: Tue Jul 15 2014 - 19:55:49 EST
On 07/15/2014 04:40 PM, Yinghai Lu wrote:
>> 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
>> 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?
We could quirk it, but we would have to make bloody darn sure that we
don't break any systems because of unusual configuration and so on.
I agree that we need to treat fixed resources as equivalent to reserved.
This is also a BIOS bug (it should reserve the whole region), but that
happens far too frequently. I don't know if we have any way to do that
without massive surgery to the current code, though.
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/