On Wed, May 31, 2006 at 01:06:26AM +0200, Petr Vandrovec wrote: > Jeremy Fitzhardinge wrote: > >On Tue, 2006-05-30 at 16:41 -0400, [EMAIL PROTECTED] wrote: > > > >>On Tue, May 30, 2006 at 12:38:01PM -0700, Jeremy Fitzhardinge wrote: > >> > >>>[snip] > >>> > >>>So the MCFG entry is in the ACPI NVS region of the E820 table. Is this > >>>bad? > >> > >>Not at all. The ACPI v3.0 specs mentions that: > >> > >>"ACPI NVS Memory. This range of addresses is in use or reserve by > >>the system and must not be used by the operating system. This > >>range is required to be saved and restored across an NVS sleep." > > > > > >I actually misread the tables. It appears that MCFG (at 0x7f6e2e36) is > >in ACPI Data (7f6d0000 - 7f6e3000). include/asm-i386/e820.h says that > >memory marked as "E820_ACPI" can be reused as normal memory once the > >ACPI tables have been read. > > > >Doesn't this mean that the MCFG memory could end up being used as > >general system memory? That seems bad if MCFG memory is some kind of > >MMIO space. Or is the comment simply wrong? > > Address where MCFG table lives is not important. What is important (and > checked) is address of MMCONFIG reported by MCFG table... Unfortunately > code does not bother with printing that address :-( > > Another problem is that code has hardcoded that MMCONFIG area is 256MB > large. Unfortunately for the code PCI specification allows any power of two > between 2MB and 256MB if vendor knows that such amount of busses (from 2 to > 128) will be sufficient for system. With notebook it is quite possible > that not full 8 bits are implemented for MMCONFIG bus number.
Patches to address this are always welcome :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
