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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 12 Jan 2009, Connor Behan wrote:
>
> 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?

As far as I can tell from the lspci, the only devices behind the docking 
bridge are

	0a:01.0 IDE interface: Silicon Image, Inc. PCI0648 (rev 01) (prog-if 8f [Master SecP SecO PriP PriO])
	0a:02.0 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller
	0a:02.1 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller

and they all like they should work. Apparently exactly because the docking 
bridge is this one:

	00:04.0 PCI bridge: Texas Instruments PCI2032 PCI Docking Bridge (prog-if 01 [Subtractive decode])

and that bridge itself is already transparent, so the fact that we 
couldn't allocate any explicit windows for it really seems like it 
shouldn't matter.

> 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.

So those are the docking bridge resources, but if I understood correctly, 
what you have issues with is that you want a graphics card in the dock to 
work - and I can't even see it in the lspci output. I see this one:

	01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02) (prog-if 00 [VGA controller])

but that is the built-in laptop graphics. You say that you have another 
graphics card that used to be at 02:00.0, but it's not showing up at ALL, 
so this is more than some random resource allocation issue - this is a 
device not even even being enumerated. That's very different - it implies 
that some bridge isn't turned on at all.

Can you do the dmesg and lspci for the kernel where this works?

		Linus