On Wed, Apr 16, 2014 at 5:08 PM, Stephane Eranian <eranian@xxxxxxxxxx> wrote: > On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote: >>> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: >>> > Right. Even if we had this long-term solution, we'd still have >>> > Stephane's current problem, because the PNP0C02 _CRS is still wrong. >>> > >>> > We do have a drivers/pnp/quirks.c where we could conceivably adjust >>> > the PNP resource if we found the matching PCI device and MCHBAR. That >>> > should solve Stephane's problem even with the current >>> > drivers/pnp/system.c. >>> >>> Guys, this still triggers in -rc1. Do we have a fix or something >>> testable at least? >> >> Hi Boris, >> >> Can you try the patch below? >> >> >> >> PNP: Work around Haswell BIOS defect in MCH area reporting >> >> From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> >> >> Work around a Haswell BIOS defect that causes part of the MCH area to be >> unreported. >> >> MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a >> PNP0C02 resource. The MCH space was 16KB prior to Haswell, but it is 32KB >> in Haswell. Some Haswell BIOSes still report a PNP0C02 resource that is >> only 16KB, which means the rest of the MCH space is consumed but >> unreported. >> > Why are you saying this is Haswell vs. others. I see the problem on my > IvyBridge laptop, like Boris. Ah, good question. Somewhere I got pointed to the Haswell docs, which say 32KB. I don't know what other parts have 32KB MCH spaces. If we could figure out a list of device IDs with 32KB spaces, we could add that to the quirk. But I don't know how to come up with a complete list. 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
