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? -hpa -- 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
