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. 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 :-) Cheers, Ben. -- 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
