On Wed, Oct 06, 2010 at 03:45:09PM -0700, H. Peter Anvin wrote: > On 10/06/2010 09:06 AM, Bjorn Helgaas wrote: > > > > On some chipsets, e.g., the AMD RS780, the MMCONFIG base address is set via > > a host bridge "BAR." But this isn't really a BAR in the sense of a decoder > > for addresses on a PCI bus. The host bridge converts host accesses to the > > MMCONFIG region into PCI configuration accesses, so the MMCONFIG addresses > > never appear on the PCI bus. > > > > In addition, this "BAR" is often larger than the MMCONFIG region proper, so > > it can overlap other real PCI devices, which causes resource allocation > > conflicts. PCI cannot move this BAR because the MMCONFIG code has already > > discovered it, so we might as well ignore it. > > > > Here's the typical signature, showing the spurious "no compatible bridge > > window" and "PNP resource overlaps PCI BAR" warnings: > > > > PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) > > pci_root PNP0A03:00: host bridge window [mem 0x7ff00000-0xfebfffff] > > pci 0000:00:00.0: BAR 3: [mem 0xe0000000-0xffffffff 64bit] > > pci 0000:00:00.0: no compatible bridge window for [mem 0xe0000000-0xffffffff 64bit] > > pnp 00:02: disabling [mem 0x00000000-0x00000fff window] because it overlaps 0000:00:00.0 BAR 3 [mem 0x00000000-0x1fffffff 64bit] > > > > Note that when we didn't find a host bridge window for the BAR, we cleared > > the resource starting address (but not the BAR register itself), leading to > > the pnp 00:02 conflict. > > This sounds like yet another case of an early-discovered resource which > needs to be treated as fixed. Any reason to not do the same thing as > for HPET and just mark them as fixed? It is similar in that we can't move it because the MMCONFIG code has already discovered it. But it's different in that the BAR reports a range that is much larger than the actual MMCONFIG range, and the excess conflicts with many other PCI and ACPI devices. The other devices work fine, so clearly the host bridge is forwarding the 0xf0000000-0xfebfffff range to PCI, not claiming it for itself. I think marking it fixed would just cause conflicts with the devices in that range rather than in the 0x00000000-0x1fffffff range. The AMD doc mentions an enable bit (HIDE_MMCFG_BAR), and I suppose we could set that and make the whole thing go away. But I sort of hate to add chipset-specific information unless we have to. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
