Re: pci 0000:01:00.0: BAR 0: can't allocate resource
Linus Torvalds
On Sun, 22 Feb 2009, George Rapp wrote:
>
> In case the attachments don't survive Gmail, dmesg output is at
> http://novia.net/~gwr/dmesg_2.6.29-0.33.rc5, and output of 'lspci -vv' is at
> http://novia.net/~gwr/lspci-vv_2.6.29-0.33.rc5
Can you also show the contents of /proc/iomem?
It does look like it's this one:
pci 0000:01:00.0: BAR 0: can't allocate mem resource [0xe0000000-0xe7ffffff]
and the problem is that the kernel cannot find enough space to map the
required 128MB region for the graphics aperture.
Which is really odd, because the bridge to that PCI bus#1 is this:
pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
pci 0000:00:01.0: IO window: 0x9000-0x9fff
pci 0000:00:01.0: MEM window: 0xf0000000-0xf1ffffff
pci 0000:00:01.0: PREFETCH window: 0x000000d8000000-0x000000e7ffffff
and that prefetch window is _huge_. Certainly big enough to fit BAR 0, but
maybe there is something else in it.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
H. Peter Anvin
>
> On Sun, 22 Feb 2009, George Rapp wrote:
>> In case the attachments don't survive Gmail, dmesg output is at
>> http://novia.net/~gwr/dmesg_2.6.29-0.33.rc5, and output of 'lspci -vv' is at
>> http://novia.net/~gwr/lspci-vv_2.6.29-0.33.rc5
>
> Can you also show the contents of /proc/iomem?
>
> It does look like it's this one:
>
> pci 0000:01:00.0: BAR 0: can't allocate mem resource [0xe0000000-0xe7ffffff]
>
> and the problem is that the kernel cannot find enough space to map the
> required 128MB region for the graphics aperture.
>
Which makes sense on 32 bits, since by default the entire vmalloc region
is only 128 MB in size.
Booting with vmalloc=256M or something like that might help.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Dave Airlie
> Linus Torvalds wrote:
>>
>> On Sun, 22 Feb 2009, George Rapp wrote:
>>> In case the attachments don't survive Gmail, dmesg output is at
>>> http://novia.net/~gwr/dmesg_2.6.29-0.33.rc5, and output of 'lspci -vv' is at
>>> http://novia.net/~gwr/lspci-vv_2.6.29-0.33.rc5
>>
>> Can you also show the contents of /proc/iomem?
>>
>> It does look like it's this one:
>>
>> pci 0000:01:00.0: BAR 0: can't allocate mem resource [0xe0000000-0xe7ffffff]
>>
>> and the problem is that the kernel cannot find enough space to map the
>> required 128MB region for the graphics aperture.
>>
>
> Which makes sense on 32 bits, since by default the entire vmalloc region
> is only 128 MB in size.
>
> Booting with vmalloc=256M or something like that might help.
>
Its not ioremap mapping it, its just getting the resource mapping for
PCI that is needed.
So nothing to do with vmalloc.
Dave.
George Rapp
On Tue, Feb 24, 2009 at 8:42 AM, George Rapp <georg...@gmail.com> wrote:
>
> On Sun, Feb 22, 2009 at 10:50 PM, Linus Torvalds <torv...@linux-foundation.org> wrote:
>>
>> Can you also show the contents of /proc/iomem?
>
> Linus -
>
> Here it is:
>
> [root@newbackend ~]# cat /proc/iomem
> 00000000-0009fbff : System RAM
> 0009fc00-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000ccfff : Video ROM
> 000d0000-000d47ff : Adapter ROM
> 000f0000-000fffff : reserved
> 000f0000-000fffff : System ROM
> 00100000-1bffffff : System RAM
> 00400000-006d8200 : Kernel code
> 006d8201-0088aa97 : Kernel data
> 008f8000-009ed14b : Kernel bss
> 01382000-01382fff : Local APIC
> d8000000-e7ffffff : PCI Bus 0000:01
> d8000000-d801ffff : 0000:01:00.0
> e8000000-efffffff : 0000:00:00.0
> f0000000-f1ffffff : PCI Bus 0000:01
> f1000000-f100ffff : 0000:01:00.0
> f2000000-f201ffff : 0000:00:0b.0
> f3000000-f307ffff : 0000:00:0c.0
> f4000000-f40001ff : 0000:00:0c.0
> f4000000-f40001ff : sata_sil
> f4001000-f400107f : 0000:00:0b.0
> ffff0000-ffffffff : reserved
Linus Torvalds
On Tue, 24 Feb 2009, George Rapp wrote:
>
> [root@newbackend ~]# 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).