Comment 7 for bug 1426216

This issue also happens with a v4.1-rc3 kernel.

Code in drivers/pci/setup-res.c:

        /*
         * If we failed to assign anything, let's try the address
         * where firmware left it. That at least has a chance of
         * working, which is better than just leaving it disabled.
         */
        if (ret < 0) {
                dev_info(&dev->dev, "BAR %d: no space for %pR\n", resno, res);
                ret = pci_revert_fw_address(res, dev, resno, size);
        }

        if (ret < 0) {
                dev_info(&dev->dev, "BAR %d: failed to assign %pR\n", resno,
                         res);
                return ret;
        }

If we do the following we can see which PCI ids failed:

 for i in $(dmesg | grep 'BAR 13: failed' | awk '{print $4}' | uniq | sort | uniq); do lspci | grep ${i%%:}; done

0001:00:00.0 PCI bridge: IBM Device 03dc
0001:01:00.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ca)
0001:02:01.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ca)
0001:02:08.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ca)
0001:02:09.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ca)
0003:00:00.0 PCI bridge: IBM Device 03dc
0003:01:00.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
0003:02:08.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
0003:02:09.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
0003:02:10.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
0003:02:11.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)

However we see all other BAR #'s allocate with no issues. It only seems to be 13 that fails.