From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: PCI Express MMCONFIG and BIOS Bug messages.. Date: Sun, 29 Apr 2007 11:27:20 -0700 Message-ID: <200704291127.21263.jbarnes@virtuousgeek.org> References: <4626C514.5010605@shaw.ca> <200704291212.03171.ak@suse.de> <4634E1F8.5000806@shaw.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: Received: from outbound-mail-66.bluehost.com ([69.89.21.26]:48305 "HELO outbound-mail-66.bluehost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1031001AbXD2SeM (ORCPT ); Sun, 29 Apr 2007 14:34:12 -0400 In-Reply-To: <4634E1F8.5000806@shaw.ca> Content-Disposition: inline Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Robert Hancock Cc: Andi Kleen , Chuck Ebbert , linux-kernel , Len Brown , linux-acpi@vger.kernel.org On Sunday, April 29, 2007, Robert Hancock wrote: > Problem is that even if we read the MMCONFIG table location from the > hardware registers, that doesn't mean we can trust the result. It could > be that the BIOS hasn't lied about where it put the table, it just stuck > it someplace completely unsuitable like on top of RAM or other > registers. It seems that with some of those 965 chipsets the latter is > what the BIOS is actually doing, and so when we think we're writing to > the table we're really writing to random chipset registers and hosing > things. (Jesse Barnes ran into this while trying to add chipset support > for the 965). Right, I've updated the BIOS since, but at least that version was totally buggy wrt MMconfig support. I haven't yet looked at the new one to see if it properly reserves MCFG space in ACPI _CRS yet or properly programs it. > Likely what we need to do is: > > -If chipset is known, take table address from registers, otherwise check > the MCFG table > -Take the resulting area (Ideally not just the first minimum part as we > check now, but the full area based on the expected length) and make sure > that the entire area is covered by a reservation in ACPI motherboard > resources. > -If that passes, then we still need to sanity check the result by making > sure it hasn't been mapped over top of something else important. How to > do this depends on exactly how they've set up the ACPI reservations on > these broken boxes.. Does someone have a full dmesg from one on a recent > kernel that shows all the pnpacpi resource reservation output? > -If these checks fail, we don't use the table, and the chipset is known, > we should likely try to disable decoding of the region so that it won't > get in the way of anything else. Yeah, that sounds like a good algorithm. I'm not sure how to handle the fact that we don't have access to the _CRS until late in boot though... Len? Jesse