On Fri, Dec 19, 2014 at 5:34 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Fri, Dec 19, 2014 at 4:23 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Mon, Dec 08, 2014 at 04:21:34PM -0800, Yinghai Lu wrote: >> >> I don't see any patches that resolve the regression (bug 85491) yet. If we >> don't figure something out, I'm going to have to revert 5b28541552ef. > > As you don't like idea to clear the MEM64 bit in resource ... > > After this merging window, I would like to post 5 patches in > > https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-pci-allocate-fit-3.18 > that will make those two systems works with "pci=realloc". It's fine with me if you post things during the merge window. But a fix that depends on adding "pci=realloc" to the kernel parameters is only a workaround, not sufficient to fix a regression. > We could have another patch that enable pci=realloc when VGA bar get > rejected at the first point. That sounds pretty hacky, but I haven't seen your patch. > The point is there is no performance difference between two solutions according > to Marek's test. I don't believe that. There might not be a difference in Marek's case, but this problem could happen with any device, and a prefetchable window clearly performs better when we do significant amounts of MMIO. I'm not interested in fixes targeted at individual cases. We have to come up with designs that are good in general. Marek's case is a little easier because his system is using _CRS. We should be able to notice that the Root Port window overlaps the host bridge window, but isn't contained by it. In that case, if we merely trim the Root Port window so it fits, everything will just work. Zermond's case is similar, but his system isn't using _CRS. If we turned on _CRS across the board instead of just for 2008 and newer, his system would be fixed, too. That's too risky for v3.19, but worth considering. I think we need to think about a different way of resolving the PowerPC issue (https://bugzilla.kernel.org/show_bug.cgi?id=74151). 5b28541552ef was one way, but certainly not the only possible approach. SeaBIOS uses a different PCI configuration strategy. It doesn't handle some of the things we need, e.g., SR-IOV, but it's worth reading for some new ideas: http://code.coreboot.org/p/seabios/source/tree/master/src/fw/pciinit.c 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
