On 22.09.2011 [10:00:11 -0700], Nishanth Aravamudan wrote: > 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? Ok may have spoken too soon (too many test kernel!) Will get back to it now :) -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
