On Thu, Apr 17, 2014 at 1:48 PM, Borislav Petkov <bp@xxxxxxxxx> wrote: > On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote: >> Thanks a lot for testing this out and debugging my issues. >> >> Here's a new version that looks for both device IDs I know about. >> >> I'm still nervous about the modeset problem Dave is seeing. Since the >> original patch wouldn't find an 8086:0c00 device on Dave's system, it >> should have done nothing. But since it caused a modesetting problem, >> there's something else doing on that I don't understand. > > Yeah, this is strange, to put it mildly. This quirk wouldnt've done > anything besides the iteration over the pci devices with pci_get_device. > Which wouldn't do anything (refcount increment or so) if it didn't find > the device, right? Right. > Bah, today is the day of the strange bugs. :-\ > >> PNP: Work around BIOS defects in Intel MCH area reporting >> >> From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> >> >> Work around BIOSes that don't report the entire Intel MCH area. >> >> MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a >> PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts. >> Some BIOSes still report a PNP0C02 resource that is only 16KB, which means >> the rest of the MCH space is consumed but unreported. >> >> This can cause resource map sanity check warnings or (theoretically) a >> device conflict if we assigned the unreported space to another device. >> >> The Intel perf event uncore driver tripped over this when it claimed the >> MCH region: >> >> resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 >> Info: mapping multiple BARs. Your kernel is fine. >> >> To prevent this, if we find a PNP0C02 resource that covers part of the MCH >> space, extend it to cover the entire space. >> >> Link: http://lkml.kernel.org/r/20140224162400.GE16457@xxxxxxx >> Reported-by: Borislav Petkov <bp@xxxxxxxxx> > > Yep, this one works fine: > > [ 0.403855] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff] > > Acked-by: Borislav Petkov <bp@xxxxxxx> > Tested-by: Borislav Petkov <bp@xxxxxxx> >> + region.end = region.start + 32*1024 - 1 ; > checkpatch complains about a trailing space before the semicolon. Thanks! I hate typos like that. I'll fix this, add your tested-by and ack, and send to Rafael. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
