linux-kernel - Re: pci 0000:01:00.0: BAR 0: can't allocate resource

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>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0902240753550.3111@localhost.localdomain>
Date:	Tue, 24 Feb 2009 08:45:20 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	George Rapp <george.rapp@...il.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Anvin <hpa@...or.com>, Dave Airlie <airlied@...il.com>
Subject: Re: pci 0000:01:00.0: BAR 0: can't allocate resource

On Tue, 24 Feb 2009, George Rapp wrote:
> 
> [root@...backend ~]# cat /proc/iomem
> ...
> d8000000-e7ffffff : PCI Bus 0000:01
>   d8000000-d801ffff : 0000:01:00.0

Ok, that's the large prefetchable PCI bridge window we would _want_ to fit 
into. And it even has something from your video card in it. In fact, I 
think it's the expansion ROM (which is not actually enabled, but the 
resource has been allocated for it).

> e8000000-efffffff : 0000:00:00.0

This is the AGP window, I think.

> f0000000-f1ffffff : PCI Bus 0000:01
>   f1000000-f100ffff : 0000:01:00.0

And this is the non-prefetchable PCI bridge window, and has the 
non-prefetchable video card resource in it.

But the odd thing is that prefetchable bridge window:

	d8000000-e7ffffff : PCI Bus 0000:01
	  d8000000-d801ffff : 0000:01:00.0

because the thing you _want_ to fit into it is this:

	pci 0000:01:00.0: BAR 0: can't allocate mem resource [0xe0000000-0xe7ffffff]

and quite frankly, it should fit perfectly fine. I'm not seeing at all why 
it can't just allocate it. Why can't we not just put it in that exact 
range: 0xe0000000-0xe7ffffff.

But there are other odd things there too. Your dmesg contains one 
tantalizing clue about the setup the BIOS used that I hadn't noticed 
before:

	pci 0000:01:00.0: reg 10 32bit mmio: [0xd0000000-0xdfffffff]
	pci 0000:01:00.0: reg 14 io port: [0x9000-0x90ff]
	pci 0000:01:00.0: reg 18 32bit mmio: [0xf1000000-0xf100ffff]
	pci 0000:01:00.0: reg 30 32bit mmio: [0x000000-0x01ffff]
	pci 0000:01:00.0: supports D1 D2

an the odd clue is that [0xd0000000-0xdfffffff]. It's the same BAR, when 
probed for initial values. And the _size_ is different. At that initial 
probe, the PCI bridge windows are set up by the BIOS (and we actually try 
to keep them, so they stay the same after PCI probing) as

	pci 0000:00:01.0: bridge io port: [0x9000-0x9fff]
	pci 0000:00:01.0: bridge 32bit mmio: [0xf0000000-0xf1ffffff]
	pci 0000:00:01.0: bridge 32bit mmio pref: [0xd8000000-0xe7ffffff]

and the _initial_ problem at that point is that we cannot reconcile the 
original video device BAR mapping (0xd0000000-0xdfffffff) with the PCI 
bridge window (0xd8000000-0xe7ffffff) since they overlap in invalid ways.

So at that point, the size of that thing is actually bigger (256M) than we 
think it's later (128M), and because it doesn't fit anywhere, we say "the 
BIOS setup must be crap, we need to re-allocate that resource". And with 
that bigger size, it really _is_ impossible to allocate.

Then at the later point, when we try to re-allocate space for it, we fail, 
but then we print out the failure and seem to think it's just 128MB in 
size:

	BAR 0: can't allocate mem resource [0xe0000000-0xe7ffffff]

(The difference in starting point is unimportant - it comes from the 
resource code having tried different starting points and failed to find 
one that satisfies us).

I wonder why the heck the sizes don't match. It also looks like the BIOS 
had set the card originally at 0xd0000000, which isn't even inside the 
bridge window. That PCI bridge is:

	00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode])

which says "normal decode", but knowing intel bridges they probably say 
that, and then they are subtractive decode after all, so the damn thing 
probably _works_ even if it's outside the bridge window.

Your machine is a mess. Has graphics _ever_ worked for you under Linux on 
that thing (not counting VESA or other braindead modes that use the 
legacy VGA apertures)?

Very odd. The 256MB size would explain why we can't seem to allocate it. 
But why do we print out the size as being 128M? And why did the BIOS do 
that crazy initial setup?

George, what happens if you ask Linux to just re-allocate all BIOS PCI bus 
window information by passing in the kernel command line

	pci=assign-busses

(and perhaps also "pci=norom", but try with just the assign-busses thing 
first).

			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/