[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo4uHcnw2yXmqTjd9w8QDa2gCDpzuZDgWCoZFT3VAd3KCg@mail.gmail.com>
Date: Wed, 16 Apr 2014 17:11:28 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Stephane Eranian <eranian@...gle.com>
Cc: Borislav Petkov <bp@...en8.de>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"Zhang, Rui" <rui.zhang@...el.com>,
"Lu, Aaron" <aaron.lu@...el.com>,
lkml <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
Linux PCI <linux-pci@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Yinghai Lu <yinghai@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"Yan, Zheng Z" <zheng.z.yan@...el.com>
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
On Wed, Apr 16, 2014 at 5:08 PM, Stephane Eranian <eranian@...gle.com> wrote:
> On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas <bhelgaas@...gle.com> 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@...gle.com>
>>
>> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists