On 22.09.2011 [07:50:13 -0600], Bjorn Helgaas wrote: > On Thu, Sep 22, 2011 at 2:48 AM, Ram Pai <linuxram@xxxxxxxxxx> wrote: > > 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. > > I don't think 2aceefcbd5 is the fix for this particular problem. It > might make the symptom go away, but we will still be checking and > potentially requesting VF resources that are disabled. > > In my opinion, when we enable the PF, with the VFs disabled, the VF > resources should not be involved at all. Ok back after some testing again! The patch I snipped in the first e-mail is needed for sure, but so is 2aceef to make the adapter function correctly. That is: 1) With my small patch to skip IOV bars in pci_enable_device, the module loads without resource conflicts (perhaps obviously true). 2) With only my small patch applied, the driver throws continuous errors and expected devices over FC aren't seen. 3) With my small patch applied and 2aceef applied, the driver functions as expected (tested with upstream before and after 2aceef was merged). So possibly 2aceef should be backported to -stable where it applies? Thanks, Nish -- Nishanth Aravamudan <nacc@xxxxxxxxxx> IBM Linux Technology Center -- 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
