On Thu, Sep 11, 2014 at 10:13:09AM +0200, David Henningsson wrote:
>
>
> On 2014-09-10 20:08, Bjorn Helgaas wrote:
> >[+cc Andreas]
> >v3.16 fails with:
> >
> > pci 0000:01:01.0: can't allocate child bus 01 from [bus 01]
> >
> >which Andreas added with fc1b253141b3 ("PCI: Don't scan random busses
> >in pci_scan_bridge()"). But I don't understand that code well enough
> >to know whether this commit is actually the cause of the problem.
> >
> >And I also haven't figured out how "pci=assign-busses" makes a difference.
> >
> >David, would you mind turning on CONFIG_DYNAMIC_DEBUG=y in your v3.16
> >kernel, adding 'dyndbg="file probe.c +p"' to your boot arguments, and
> >collecting another dmesg log?
>
> Thanks for looking at this (and sorry for not having done a bisect yet).
>
> Anyhow, a new dmesg log has now been posted at kernel bugzilla
> #83441. It has a few more lines starting with "pci_bus" but nothing
> that really stands out AFAICT.
We need to make progress on this regression before v3.17. David, can you
test the following revert (on top of v3.17-rc2)? If it works, I plan to
apply it for v3.17 (unless we have a better solution, of course).
Bjorn
commit 413db4234ebbb9750f01180c04965ad3a5e18986
Author: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
Date: Fri Sep 12 20:46:09 2014 -0600
Revert "PCI: Don't scan random busses in pci_scan_bridge()"
This reverts commit fc1b253141b3 ("PCI: Don't scan random busses in
pci_scan_bridge()") because it breaks CardBus on some machines.
David tested a Dell Latitude D505 that worked like this prior to
fc1b253141b3:
pci 0000:00:1e.0: PCI bridge to [bus 01]
pci 0000:01:01.0: CardBus bridge to [bus 02-05]
Note that the 01:01.0 CardBus bridge has a bus number aperture of
[bus 02-05], but those buses are all outside the 00:1e.0 PCI bridge bus
number aperture, so accesses to buses 02-05 never reach CardBus. This is
later patched up by yenta_fixup_parent_bridge(), which changes the
subordinate bus number of the 00:1e.0 PCI bridge:
pci_bus 0000:01: Raising subordinate bus# of parent bus (#01) from #01 to #05
With fc1b253141b3, pci_scan_bridge() just fails immediately when it notices
that we can't allocate a valid secondary bus number for the CardBus bridge,
and CardBus doesn't work at all:
pci 0000:01:01.0: can't allocate child bus 01 from [bus 01]
I'd prefer to fix this by integrating the yenta_fixup_parent_bridge() logic
into pci_scan_bridge() so we fix the bus number apertures up front. But
that's a bigger effort, and I want to fix the regression while we're
working on it.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=83441
Link: http://lkml.kernel.org/r/1409303414-5196-1-git-send-email-david.henningsson@xxxxxxxxxxxxx
Reported-by: David Henningsson <david.henningsson@xxxxxxxxxxxxx>
Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
CC: stable@xxxxxxxxxxxxxxx # v3.15+
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e3cf8a2e6292..7c8ca351beae 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -838,16 +838,12 @@ int pci_scan_bridge(struct pci_bus *bus, struct pci_dev *dev, int max, int pass)
goto out;
}
- if (max >= bus->busn_res.end) {
- dev_warn(&dev->dev, "can't allocate child bus %02x from %pR\n",
- max, &bus->busn_res);
- goto out;
- }
-
/* Clear errors */
pci_write_config_word(dev, PCI_STATUS, 0xffff);
- /* The bus will already exist if we are rescanning */
+ /* Prevent assigning a bus number that already exists.
+ * This can happen when a bridge is hot-plugged, so in
+ * this case we only re-scan this bus. */
child = pci_find_bus(pci_domain_nr(bus), max+1);
if (!child) {
child = pci_add_new_bus(bus, dev, max+1);
--
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
