Re: PCI Express MMCONFIG and BIOS Bug messages..

[Robert Hancock <hancockr@shaw.ca>]

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@nospamshaw.ca
Home Page: http://www.roberthancock.com/


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