On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote:

> Anyways I would say that if the BIOS can't get MCFG right then
> it's likely not been validated on that board and shouldn't be used.

According to Petr Vandrovec:

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

So here is a patch.  Unfortunately my system still fails the test because
it doesn't reserve any part of the MMCONFIG area, but this may fix others.

Booted on x86_64, only compiled on i386.  x86_64 still remaps the max area
(256MB) even though only 2MB is checked... but 2.6.16 had no check at all
so it is still better.

PCI: reduce size of x86 MMCONFIG reserved area check

1.  Print the address of the MMCONFIG area when the test for that area
    being reserved fails.

2.  Only check if the first 2MB is reserved, as that is the minimum.
Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Nobody should pass NULL here. Could in theory make it a BUG,
but the NULL pointer oops will do as well.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Mostly to get better handling when a extended config space
access has to fallback to Type1.

Cc: gregkh@suse.de
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Previously only the first bus would be checked against Type 1.

Why 16? Checking all would need too much memory and we
can assume that systems with more than 16 busses have better than
average quality BIOS.

This is an additional defense against bad MCFG tables.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch introduces a user for the e820_all_mapped function:

There have been several machines that don't have a working MMCONFIG,
often because of a buggy MCFG table in the ACPI bios.  This patch adds a
simple sanity check that detects a whole bunch of these cases, and when
it detects it, linux now boots rather than crash-and-burns.

The accuracy of this detection can in principle be improved if there was
a "is this entire range in e820 with THIS attribute", but no such
function exist and the complexity needed for this is not really worth
it; this simple check already catches most cases anyway.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I moved it to a separate function which is safer.

This avoids problems with the linker reordering them and the
less useful PCI config space access methods taking priority
over the better ones.

Fixes some problems with broken MMCONFIG

Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Handle more bogus MCFG entries

Some Asus P4 boards seem to have broken MCFG tables with
only a single entry for busses 0-0.  Special case these
and assume they mean all busses can be accessed.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use correct address when referencing mmconfig aperture while checking
for broken MCFG.  This was a typo when porting the code from 64bit to
32bit.  It caused oopses at boot on some ThinkPads.

Should definitely go into 2.6.15.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

They report all busses as MMCONFIG capable, but it never works for the
internal devices in the CPU's builtin northbridge.

It just probes all func 0 devices on bus 0 (the internal northbridge is
currently always on bus 0) and if they are not accessible using MCFG they are
put into a special fallback bitmap.

On systems where it isn't we assume the BIOS vendor supplied correct MCFG.

Requires the earlier patch for mmconfig type1 fallback
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When there is no entry for a bus in MCFG fall back to type1.  This is
especially important on K8 systems where always some devices can't be accessed
using mmconfig (in particular the builtin northbridge doesn't support it for
its own devices)

Cc: <gregkh@suse.de>
Cc: <jgarzik@pobox.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Now that Greg implemented MCFG/_SEG support this shouldn't be needed
anymore

Cc: gregkh@suse.de
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Now that we have access to the whole MCFG table, let's properly use it
for all pci device accesses (as that's what it is there for, some boxes
don't put all the busses into one entry.)

If, for some reason, the table is incorrect, we fallback to the "old
style" of mmconfig accesses, namely, we just assume the first entry in
the table is the one for us, and blindly use it.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch is the first step in properly handling the MCFG PCI table.
It defines the structures properly, and saves off the table so that the
pci mmconfig code can access it.  It moves the parsing of the table a
little later in the boot process, but still before the information is
needed.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!