ThinkPad X60: PCI: BIOS Bug: MCFG area is not E820-reserved (MCFG is in ACPI NVS)

ThinkPad X60: PCI: BIOS Bug: MCFG area is not E820-reserved (MCFG is in ACPI NVS)

[Jeremy Fitzhardinge]

I'm getting the message:

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


when I boot 2.6.17-rc5 on my Lenovo Thinkpad X60.  I don't know if this 
is a problem; the machine seems to work fine.

The E820 table reported at boot says:

BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007f6d0000 (usable)
BIOS-e820: 000000007f6d0000 - 000000007f6e3000 (ACPI data)
BIOS-e820: 000000007f6e3000 - 000000007f700000 (ACPI NVS)
BIOS-e820: 000000007f700000 - 0000000080000000 (reserved)
BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)

and the ACPI tables are:

Using APIC driver default
ACPI: RSDP (v002 LENOVO                                ) @ 0x000f6880
ACPI: XSDT (v001 LENOVO TP-7B    0x00001060  LTP 0x00000000) @ 0x7f6d6621
ACPI: FADT (v003 LENOVO TP-7B    0x00001060 LNVO 0x00000001) @ 0x7f6d6700
ACPI: SSDT (v001 LENOVO TP-7B    0x00001060 MSFT 0x0100000e) @ 0x7f6d68b4
ACPI: ECDT (v001 LENOVO TP-7B    0x00001060 LNVO 0x00000001) @ 0x7f6e2d4a
ACPI: TCPA (v002 LENOVO TP-7B    0x00001060 LNVO 0x00000001) @ 0x7f6e2d9c
ACPI: MADT (v001 LENOVO TP-7B    0x00001060 LNVO 0x00000001) @ 0x7f6e2dce
ACPI: MCFG (v001 LENOVO TP-7B    0x00001060 LNVO 0x00000001) @ 0x7f6e2e36
ACPI: HPET (v001 LENOVO TP-7B    0x00001060 LNVO 0x00000001) @ 0x7f6e2e74
ACPI: BOOT (v001 LENOVO TP-7B    0x00001060  LTP 0x00000001) @ 0x7f6e2fd8
ACPI: SSDT (v001 LENOVO TP-7B    0x00001060 INTL 0x20050513) @ 0x7f6d5bdc
ACPI: SSDT (v001 LENOVO TP-7B    0x00001060 INTL 0x20050513) @ 0x7f6d5a04
ACPI: DSDT (v001 LENOVO TP-7B    0x00001060 MSFT 0x0100000e) @ 0x00000000

So the MCFG entry is in the ACPI NVS region of the E820 table.  Is this 
bad? The code in arch/i386/pci/mmconfig.c only checks for MCFG being in 
an E820_RESERVED area.  Should it also check for E820_NVS?

This FC5 stock kernels (such as kernel-smp-2.6.16-1.2122_FC5) don't 
appear to have this check (no message printed), and they work fine on 
this machine.

Thanks,
   J

Re: ThinkPad X60: PCI: BIOS Bug: MCFG area is not E820-reserved (MCFG is in ACPI NVS)

[konradr]

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."

In other words, it is similar to what Reserved is set to - except the
Non-Volatile Sleep area can be used when S4 save/restore occurs.

> The code in arch/i386/pci/mmconfig.c only checks for MCFG being in 
> an E820_RESERVED area.  Should it also check for E820_NVS?

IMHO, based on the PCI 3.0 spec, the whole check should be removed - 
as the MCFG memory region does not have to be reserved in E820 table.

Re: ThinkPad X60: PCI: BIOS Bug: MCFG area is not E820-reserved (MCFG is in ACPI NVS)

[Jeremy Fitzhardinge]

On Tue, 2006-05-30 at 16:41 -0400, konradr@us.ibm.com 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?

(I don't really know what this stuff is, so maybe I'm just pointlessly
worrying.)

	J

Re: ThinkPad X60: PCI: BIOS Bug: MCFG area is not E820-reserved (MCFG is in ACPI NVS)

[Petr Vandrovec]

Jeremy Fitzhardinge wrote:
> On Tue, 2006-05-30 at 16:41 -0400, konradr@us.ibm.com 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.
								Petr

Re: ThinkPad X60: PCI: BIOS Bug: MCFG area is not E820-reserved (MCFG is in ACPI NVS)

[Greg KH]

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, konradr@us.ibm.com 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