On Thu, Sep 22, 2011 at 09:41:23AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2011-09-22 at 07:26 +0800, Ram Pai wrote: > > > With this change, the driver does load, although there do still appear > > > to be problems with upstream at that point that I'm still tracking down. > > > > > > The thinking is that it shouldn't be an error at this point in the code > > > if we fail to enable the IOV BARs as we're not enabling IOV here in the > > > first place. The failure point should be when the driver attempts to > > > create VFs if we can't use the IOV BARs. > > > > > > I have a few questions: > > > > > > 1) Does this make sense to you? :) > > > > > > 2) Presuming the fix above *isn't* ok, do you have thoughts on > > > a better approach? Keeping in mind that on power, we don't > > > control the device resource assignment, so we are a little more > > > stuck here, arguably. > > > > Sounds like your BIOS/Firmware allocates conflicting memory resources to the > > SRIOV BARs. There is code enabled recently in 3.1 kernel that tries to > > reallocate and resolve conflicts. Does that work for you? > > The BIOS/Firmware is pHyp :-) > > It does not allocate any resource for SR-IOV. It doesn't know about the > IOV BAR at all. And because it controls all resources allocated to the > partition, we cannot fix that up ourselves. > > We simply need to ignore the IOV BAR when enabling the device for > "normal" (ie non IOV) usage. We should only fail attempts at enabling > VFs. There is one other patch that makes SRIOV BARs optional. It will not enable those BARs unless there is enough non-conflicting resource available for it. git commit 2aceefcbd5a73059e5f52831817ec277e987440d Hopefully that will take care of the problem. > > Now there seem to be other issues with some adapters as well, some of > the stuff done in sriov_init() breaks the lpfc driver in other ways on > those machines, Nish is still investigating. I suspect the unconditional > setting of the page size. That's definitely a bad idea. > > Overall though, it boils down to SR-IOV is a very poorly designed > standard and now we have to face poor implementations of it :-) hmm..how so? ;) RP -- 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
