Re: Can't allocate resources for PCI video card behind bridge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry for being away over the weekend.
Here's how I interpret your lspci at http://pastebin.com/f126dc794;
see if it makes sense to you:

Bus 00 has a bunch of devices that are built into the laptop.
Bus 01 has your built-in VGA below the AGP bridge at 00:01.0.
Buses 02-05 are for a laptop CardBus slot below the bridge at 00:02.0.
Buses 06-09 are for a laptop CardBus slot below the bridge at 00:02.1.
Buses 0a-12 are for things below the docking bridge at 00:04.0.
Buses 0b-0e are for a Dock II CardBus slot below the bridge at 0a:02.0. Buses 0f-12 are for a Dock II CardBus slot below the bridge at 0a:02.1.

I don't see your plug-in X1550 card.  If it were there, I suppose the
PCI to PCI-E bridge would be on bus 0a, with the actual video device
on some secondary bus like 13?
Most of that makes sense, I think the PCI to PCI-E bridge was somewhere on bus 0a but the VGA Compatible Controller was definitely bus 02. The busses only go up to 0a because I'm using pci=assign-busses. If I don't use that, they stop at 12.
It may be that we want the "don't allocate resources for transparent bridges"
patch after all:

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index ea979f2..586451c 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -467,8 +467,12 @@ void __ref pci_bus_size_bridges(struct pci_bus *bus)
                 }
         }

-       /* The root bus? */
-       if (!bus->self)
+       /*
+        * We don't need to allocate PCI bridging windows
+        * for a root bus (everything bridged) or for a
+        * transparent one.
+        */
+       if (!bus->self || bus->self->transparent)
                 return;
I don't understand this transparent bridge stuff very well, but it's
common for a bridge to support both positive and subtractive decode.
In that case, don't we still want to allocate resources for the
positive decode windows?

I tried this patch but the kernel I'm using with that applied gives me the following dmesg: http://pastebin.com/f7a01c86 and the following lspci -vvv: http://pastebin.com/f3e473a13. Are there any other patches that claim to solve this? I know it can be solved without patches because of that one fluke attempt where it worked - I just had no way of knowing which options actually contributed to that success while it lasted. The only thing I remember about my dmesg output when I had this working was that it did NOT give the "can't allocate resource" errors for BARs 7, 8 and 9.
--
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

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux