Messages in this thread | | | Date | Tue, 15 Jul 2014 16:40:07 -0700 | Subject | Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() | From | Yinghai Lu <> |
| |
On Tue, Jul 15, 2014 at 1:33 PM, Bjorn Helgaas <bhelgaas@google.com> 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
| |