Chuck Ebbert wrote:
Robert Hancock wrote:
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.
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..
Intel had posted patches to do exactly that, but they were rejected.
I don't remember why now...
I tried adapting a patch by Rajesh Shah to do this for current kernels:
http://lkml.org/lkml/2006/6/23/365
It walks through all the motherboard resource devices and tries to pull
out the resource settings for all of them using the _CRS method.
(Depending on how you do the probing, the _STA method is called as well,
either before or after.) From my limited ACPI knowledge, the problem is
that the PCI MMCONFIG initialization is called before the main ACPI
interpreter is enabled, and these control methods may try to access
operation regions who don't have handlers set up for them yet, so a
bunch of "no handler for region" errors show up.
I think some earlier version of this patch was in -mm for a while back
in 2.6.18 times, I actually complained about it back then because it
falsely detected the region wasn't reserved on my system since it bailed
out on the first such error before it found the reservation. On my
system it turns out that the device called EXPL that has the MCFG table
reservation in it has the addresses statically defined in the _CRS
method and doesn't need to access any regions, so if you make the search
continue on after errors, it does actually work, but there's probably no
guarantee that all systems will have the MCFG reservation statically
defined like this, and we can't have all those ACPI errors from other
devices clogging the logs either.
So essentially if we want to do this check based on ACPI resource
reservations, we need to be able to execute control methods at the point
that MMCONFIG is set up. Is there a reason why this can't be made
possible (like by moving the necessary parts of ACPI initialization
earlier)?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.com/
-
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
