[-cc Saifi (bouncing)] On Mon, Dec 8, 2014 at 2:38 PM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 2014-12-08 at 14:04 -0700, Bjorn Helgaas wrote: >> >> However, I think 5b28541552ef is taking the wrong approach. Consider >> a device that, like this Radeon, has a 32-bit prefetchable BAR. If >> the upstream bridge has a 32-bit prefetchable window, things work as >> expected -- we put the prefetchable BAR in the prefetchable window. >> But if the bridge has a 64-bit prefetchable window, we put that same >> BAR in a 32-bit non-prefetchable window. > > Well, that's expected, unless the 64-bit prefetchable window happens to > be fully enclosed in 32-bit space ... So maybe the approach is to check > that this is the case and "downgrade" such 64-bit prefetchable BARs to > 32-bit ... Yeah, I didn't word that very clearly. I meant that after 5b28541552ef, that 64-bit window is wasted unless there's a 64-bit BAR below it; we can't even place the window below 4GB and use it for 32-bit prefetchable BARs. >> So we upgraded the system with a better bridge, i.e., it supports a >> full 64-bit window instead of just a 32-bit window, and the system >> performs WORSE. That's what I think is fundamentally broken. >> >> > Looking at bug#85491 and the logs from Marek, BIOS didn't configure >> windows >> > and BARs for PCI bridge and adapters properly, which forces the >> kernel to >> > reassign those BARs/windows failing to be claimed previously. If I'm >> correct, >> > we need a way to reassign the bridge's non-prefetchable window and >> with it, >> > find_free_bus_resource() needn't check on "!r->parent". >> >> It's true that the BIOS didn't configure things correctly. But we >> can't use that as an excuse; the kernel should be able to configure >> things correctly itself because there are plenty of machines where the >> BIOS never configures things. > > -- 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
