| Message ID | 4AA17DB4.8040704@intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 40e75f6..62c0c17 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1094,6 +1094,10 @@ unsigned int __devinit pci_scan_child_bus(struct pci_bus *bus) /* Reserve buses for SR-IOV capability. */ max += pci_iov_bus_range(bus); + /* Shift all bus numbers by 1 in the hopes of creating a conflict */ + if (bus->number == 0) + max += 1; + /* * After performing arch-dependent fixup of the bus, look behind * all PCI-to-PCI bridges on this bus.
Hi, I think I found an issue with the pci=assign-busses option when trying to work around a system that has SR-IOV disabled. I believe I have narrowed down the issue to a problem of bridge routing but I am not certain how best to go about resolving the issue. Below is a snippet from an lspci -t when the devices appear as they are supposed to. With the patch included at the end of the email applied it changes to the broken layout. I originally found the issue while testing SR-IOV on a system with 7 82576 quad port adapters. The issue appears to occur when the upstream secondary bus matches one of the downstream secondary buses. When it occurs the system is unable to detect some or all of the downstream ports. I generated the patch below as a debugging step so that I could target specific buses when reproducing the issue. In the example below I saw the issue when the secondary bus on the upstream port was 3 or 4, but once it went to 5 the devices appeared again without issue. I was also able to work around my SR-IOV issue by increasing the buses sufficiently that there was no upstream/downstream overlap. The issue doesn't appear to be bridge specific as I can recreate it on Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port, Integrated Device Technology, Inc. PES12N3A PCI Express Switch, and a Integrated Device Technology, Inc. PES24N3A PCI Express Switch. Thanks, Alex What it should looks like without the change: -[0000:00]-+-00.0 +-01.0-[0000:01-04]----00.0-[0000:02-04]--+-02.0-[0000:03]--+-00.0 | | \-00.1 | \-04.0-[0000:04]--+-00.0 | \-00.1 What it looks like when broken: -[0000:00]-+-00.0 +-01.0-[0000:02-03]----00.0-[0000:03-03]-- | | | -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html