On 09/20/2011 08:48 PM, Nishanth Aravamudan wrote:
Hi Jesse,
We've gotten a few reports of the following situation: a SR-IOV capable
adapter in a ppc64 server (in some cases driven by the lpfc driver, in
others by the be2net driver, but I don't think it is driver specific)
fails to initialize due to a collision on BAR 7 (the first IOV
resource), e.g.:
0000:98:00.1: device not available (can't reserve [mem 0xfffe0000-0x1001dffff 64bit])
I'm testing the following change:
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4e84fd4..17b651e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1126,9 +1126,14 @@ static int __pci_enable_device_flags(struct pci_dev *dev,
if (atomic_add_return(1,&dev->enable_cnt)> 1)
return 0; /* already enabled */
- for (i = 0; i< DEVICE_COUNT_RESOURCE; i++)
+ for (i = 0; i< DEVICE_COUNT_RESOURCE; i++) {
+#ifdef CONFIG_PCI_IOV
+ if (i>= PCI_IOV_RESOURCES&& i<= PCI_IOV_RESOURCE_END)
+ continue;
+#endif
if (dev->resource[i].flags& flags)
bars |= (1<< i);
+ }
err = do_pci_enable_device(dev, bars);
if (err< 0)
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.
You're talking about what is essentially (or should be) a runtime
decision, but the patch presents a compile-time decision...
Jeff
--
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
