public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: Andi Kleen <ak@suse.de>
Subject: PCI Express MMCONFIG and BIOS Bug messages..
Date: Wed, 18 Apr 2007 19:25:40 -0600	[thread overview]
Message-ID: <4626C514.5010605@shaw.ca> (raw)

I've seen a lot of systems (including brand new Xeon-based servers from 
IBM and HP) that output messages on boot like:

PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved
PCI: Not using MMCONFIG.

As I understand it, this is sort of a sanity check mechanism to make 
sure the MCFG address reported is remotely reasonable and intended to be 
used as such. Problem is, I doubt the BIOS authors would agree that this 
constitutes a bug. Microsoft is providing a lot of the direction for 
BIOS writers, and have a look at this presentation "PCI Express, 
Windows, And The Legacy Transition" from back in 2004:

http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04047_WINHEC2004.ppt

On page 14, "Existing Windows - Reserve MMCONFIG":

Existing Windows versions won’t understand MCFG table
* Backwards-compatible range reservation must be used
Report range in ACPI "Motherboard Resources"
*_CRS of PNP0C02 node
* PNP0C02 must be at \_SB scope
* Range must be marked as consumed
Do not include range in _CRS of PCI root bus
* If included, OS will assume that this range can be allocated to devices
E820 table/EFI memory map
  * Not necessary to describe MMConfig here
  * For Windows, these are used to describe RAM
  * No harm in including range as reserved either

So Microsoft is explicitly telling the BIOS developers that there is no 
need to reserve the MMCONFIG space in the E820 table because Windows 
doesn't care. On that basis it doesn't seem like a valid check to 
require it to be so reserved, then.

Really, I think we should be basing this check on whether the 
corresponding memory range is reserved in the ACPI resources, like 
Windows expects. This does require putting more fingers into ACPI from 
this early boot stage, though..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


             reply	other threads:[~2007-04-19  1:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-19  1:25 Robert Hancock [this message]
2007-04-19 16:05 ` PCI Express MMCONFIG and BIOS Bug messages Chuck Ebbert
2007-04-29  1:22   ` Robert Hancock
2007-04-29 10:12     ` Andi Kleen
2007-04-29 18:20       ` Robert Hancock
2007-04-29 18:27         ` Jesse Barnes
2007-04-29 18:39           ` Robert Hancock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4626C514.5010605@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox