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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Jan 2009 19:05:06 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Connor Behan <connor.behan@...il.com>
cc:	Grant Grundler <grundler@...isc-linux.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	Linux PCI <linux-pci@...r.kernel.org>,
	Gary Hade <garyhade@...ibm.com>
Subject: Re: Can't allocate resources for PCI video card behind bridge

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/