Re: PCI Express MMCONFIG and BIOS Bug messages..

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
Home Page: http://www.roberthancock.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux