Hello, I am trying to use two video cards. One is the built in ATI Rage
Mobility M3 AGP card which drives the screen of my laptop (Thinkpad a22m
2628-S1U if that matters), the other is the ATI Radeon X1550 PCI card in
the Thinkpad Dock II which is supposed to drive an external monitor.
X1550 is a PCI-E chipset but my card is a PCI card with an onboard PCI
to PCI-E bridge. I first tried this with kernel 2.6.27 as packaged by
Archlinux and got the following startup errors:
pci 0000:00:04.0: BAR 7: can't allocate resource
pci 0000:00:04.0: BAR 8: can't allocate resource
pci 0000:00:04.0: BAR 9: can't allocate resource
I've seen this problem discussed in the archives and couldn't find what
looked like a fix. I WAS able to fix this by loading dock, pci_slot,
pci_hotplug and acpiphp and appending pci=assign-busses. However since
then I have run a package update to kernel 2.6.27.10 and I am once again
getting the same problem even with the same modules and parameters. I
have since tried appending irqpoll, pci=bios, pci=routeirq and acpi=off
with no success. I have even rolled back my kernel to 2.6.27 (and the
headers and a few other packages) setup my system the way it was setup
before to the best of my knowledge but I still can't get the PCI card
working again. Another subtle change must be responsible.
Certain PCI devices in the dock are working such as the Cardbus slots...
but I could care less about them... is there a way I could tell the
kernel to prioritize the video card and sacrifice Cardbus slots first if
it can't allocate enough resources? Also my lspci output shows a large
gap 01:00.0 to 06:00.0 so some part of my system must have expected
other devices in that range. When I had the video card working it was
02:00.0. I have tried changing the four IRQ numbers in the BIOS but this
is pointless at best and sometimes causes my soundcard to be disabled.
My dmesg, lspci and (trimmed) kernel config are pasted:
dmesg: http://pastebin.com/f3ae15a58
lspci: http://pastebin.com/f5d7dee6e
.config: http://pastebin.com/fb925760
I'm hoping for a solution that doesn't require recompiling the kernel
but I definitely would if that's necessary. In any event I'll be much
more vigilant about system updates if I get this working again.
Thank-you very much for your time.
Cc-ing linux-pci and Jesse.
On Thursday 08 January 2009, Connor Behan wrote:
> Hello, I am trying to use two video cards. One is the built in ATI Rage
> Mobility M3 AGP card which drives the screen of my laptop (Thinkpad a22m
> 2628-S1U if that matters), the other is the ATI Radeon X1550 PCI card in
> the Thinkpad Dock II which is supposed to drive an external monitor.
> X1550 is a PCI-E chipset but my card is a PCI card with an onboard PCI
> to PCI-E bridge. I first tried this with kernel 2.6.27 as packaged by
> Archlinux and got the following startup errors:
>
> pci 0000:00:04.0: BAR 7: can't allocate resource
> pci 0000:00:04.0: BAR 8: can't allocate resource
> pci 0000:00:04.0: BAR 9: can't allocate resource
>
> I've seen this problem discussed in the archives and couldn't find what
> looked like a fix. I WAS able to fix this by loading dock, pci_slot,
> pci_hotplug and acpiphp and appending pci=assign-busses. However since
> then I have run a package update to kernel 2.6.27.10 and I am once again
> getting the same problem even with the same modules and parameters. I
> have since tried appending irqpoll, pci=bios, pci=routeirq and acpi=off
> with no success. I have even rolled back my kernel to 2.6.27 (and the
> headers and a few other packages) setup my system the way it was setup
> before to the best of my knowledge but I still can't get the PCI card
> working again. Another subtle change must be responsible.
>
> Certain PCI devices in the dock are working such as the Cardbus slots...
> but I could care less about them... is there a way I could tell the
> kernel to prioritize the video card and sacrifice Cardbus slots first if
> it can't allocate enough resources? Also my lspci output shows a large
> gap 01:00.0 to 06:00.0 so some part of my system must have expected
> other devices in that range. When I had the video card working it was
> 02:00.0. I have tried changing the four IRQ numbers in the BIOS but this
> is pointless at best and sometimes causes my soundcard to be disabled.
> My dmesg, lspci and (trimmed) kernel config are pasted:
>
> dmesg: http://pastebin.com/f3ae15a58
> lspci: http://pastebin.com/f5d7dee6e
> .config: http://pastebin.com/fb925760
>
> I'm hoping for a solution that doesn't require recompiling the kernel
> but I definitely would if that's necessary. In any event I'll be much
> more vigilant about system updates if I get this working again.
> Thank-you very much for your time.
On Thursday, January 8, 2009 11:56 am Rafael J. Wysocki wrote:
> Cc-ing linux-pci and Jesse.
>
> On Thursday 08 January 2009, Connor Behan wrote:
> > Hello, I am trying to use two video cards. One is the built in ATI Rage
> > Mobility M3 AGP card which drives the screen of my laptop (Thinkpad a22m
> > 2628-S1U if that matters), the other is the ATI Radeon X1550 PCI card in
> > the Thinkpad Dock II which is supposed to drive an external monitor.
> > X1550 is a PCI-E chipset but my card is a PCI card with an onboard PCI
> > to PCI-E bridge. I first tried this with kernel 2.6.27 as packaged by
> > Archlinux and got the following startup errors:
> >
> > pci 0000:00:04.0: BAR 7: can't allocate resource
> > pci 0000:00:04.0: BAR 8: can't allocate resource
> > pci 0000:00:04.0: BAR 9: can't allocate resource
> >
> > I've seen this problem discussed in the archives and couldn't find what
> > looked like a fix. I WAS able to fix this by loading dock, pci_slot,
> > pci_hotplug and acpiphp and appending pci=assign-busses. However since
> > then I have run a package update to kernel 2.6.27.10 and I am once again
> > getting the same problem even with the same modules and parameters. I
> > have since tried appending irqpoll, pci=bios, pci=routeirq and acpi=off
> > with no success. I have even rolled back my kernel to 2.6.27 (and the
> > headers and a few other packages) setup my system the way it was setup
> > before to the best of my knowledge but I still can't get the PCI card
> > working again. Another subtle change must be responsible.
> >
> > Certain PCI devices in the dock are working such as the Cardbus slots...
> > but I could care less about them... is there a way I could tell the
> > kernel to prioritize the video card and sacrifice Cardbus slots first if
> > it can't allocate enough resources? Also my lspci output shows a large
> > gap 01:00.0 to 06:00.0 so some part of my system must have expected
> > other devices in that range. When I had the video card working it was
> > 02:00.0. I have tried changing the four IRQ numbers in the BIOS but this
> > is pointless at best and sometimes causes my soundcard to be disabled.
> > My dmesg, lspci and (trimmed) kernel config are pasted:
> >
> > dmesg: http://pastebin.com/f3ae15a58
> > lspci: http://pastebin.com/f5d7dee6e
> > .config: http://pastebin.com/fb925760
> >
> > I'm hoping for a solution that doesn't require recompiling the kernel
> > but I definitely would if that's necessary. In any event I'll be much
> > more vigilant about system updates if I get this working again.
> > Thank-you very much for your time.
Can you post the output of lspci -vvv somewhere as well after trying 2.6.28?
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;
switch (bus->self->class >> 8) {
Since in your case it looks like it's incorrectly causing some of your other
resources to be disabled:
pnp 00:02: io resource (0x22-0x22) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff),
disabling
pnp 00:02: io resource (0x92-0x92) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff),
disabling
pnp 00:02: io resource (0xb2-0xb3) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff),
disabling
pnp 00:0a: io resource (0x2e-0x2f) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff),
disabling
Sorry but you might have to build a few kernels to help us fix this one. :)
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, Jan 08, 2009 at 12:26:38PM -0800, Jesse Barnes wrote:
> On Thursday, January 8, 2009 11:56 am Rafael J. Wysocki wrote:
> > Cc-ing linux-pci and Jesse.
> >
> > On Thursday 08 January 2009, Connor Behan wrote:
> > > Hello, I am trying to use two video cards. One is the built in ATI Rage
> > > Mobility M3 AGP card which drives the screen of my laptop (Thinkpad a22m
> > > 2628-S1U if that matters), the other is the ATI Radeon X1550 PCI card in
> > > the Thinkpad Dock II which is supposed to drive an external monitor.
> > > X1550 is a PCI-E chipset but my card is a PCI card with an onboard PCI
> > > to PCI-E bridge. I first tried this with kernel 2.6.27 as packaged by
> > > Archlinux and got the following startup errors:
> > >
> > > pci 0000:00:04.0: BAR 7: can't allocate resource
> > > pci 0000:00:04.0: BAR 8: can't allocate resource
> > > pci 0000:00:04.0: BAR 9: can't allocate resource
> > >
> > > I've seen this problem discussed in the archives and couldn't find what
> > > looked like a fix. I WAS able to fix this by loading dock, pci_slot,
> > > pci_hotplug and acpiphp and appending pci=assign-busses. However since
> > > then I have run a package update to kernel 2.6.27.10 and I am once again
> > > getting the same problem even with the same modules and parameters. I
> > > have since tried appending irqpoll, pci=bios, pci=routeirq and acpi=off
> > > with no success. I have even rolled back my kernel to 2.6.27 (and the
> > > headers and a few other packages) setup my system the way it was setup
> > > before to the best of my knowledge but I still can't get the PCI card
> > > working again. Another subtle change must be responsible.
> > >
> > > Certain PCI devices in the dock are working such as the Cardbus slots...
> > > but I could care less about them... is there a way I could tell the
> > > kernel to prioritize the video card and sacrifice Cardbus slots first if
> > > it can't allocate enough resources? Also my lspci output shows a large
> > > gap 01:00.0 to 06:00.0 so some part of my system must have expected
> > > other devices in that range. When I had the video card working it was
> > > 02:00.0. I have tried changing the four IRQ numbers in the BIOS but this
> > > is pointless at best and sometimes causes my soundcard to be disabled.
> > > My dmesg, lspci and (trimmed) kernel config are pasted:
> > >
> > > dmesg: http://pastebin.com/f3ae15a58
> > > lspci: http://pastebin.com/f5d7dee6e
> > > .config: http://pastebin.com/fb925760
> > >
> > > I'm hoping for a solution that doesn't require recompiling the kernel
> > > but I definitely would if that's necessary. In any event I'll be much
> > > more vigilant about system updates if I get this working again.
> > > Thank-you very much for your time.
>
> Can you post the output of lspci -vvv somewhere as well after trying 2.6.28?
> 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;
>
> switch (bus->self->class >> 8) {
Jesse, I think this change is doing the same thing as
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8fa5913d54f3b1e09948e6a0db34da887e05ff1f
which was reverted by
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=12c22d6ef299ccf0955e5756eb57d90d7577ac68
because of
http://bugzilla.kernel.org/show_bug.cgi?id=10080
http://marc.info/?l=linux-kernel&m=120620382316329&w=2
http://marc.info/?l=linux-kernel&m=120653981716729&w=2
It definitely seems like the right thing to do but it apparently
breaks stuff on systems with oddball transparent bridges.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
Gary Hade wrote:
> On Thu, Jan 08, 2009 at 12:26:38PM -0800, Jesse Barnes wrote:
>
>> On Thursday, January 8, 2009 11:56 am Rafael J. Wysocki wrote:
>>
>>> Cc-ing linux-pci and Jesse.
>>>
>>> On Thursday 08 January 2009, Connor Behan wrote:
>>>
>>>> Hello, I am trying to use two video cards. One is the built in ATI Rage
>>>> Mobility M3 AGP card which drives the screen of my laptop (Thinkpad a22m
>>>> 2628-S1U if that matters), the other is the ATI Radeon X1550 PCI card in
>>>> the Thinkpad Dock II which is supposed to drive an external monitor.
>>>> X1550 is a PCI-E chipset but my card is a PCI card with an onboard PCI
>>>> to PCI-E bridge. I first tried this with kernel 2.6.27 as packaged by
>>>> Archlinux and got the following startup errors:
>>>>
>>>> pci 0000:00:04.0: BAR 7: can't allocate resource
>>>> pci 0000:00:04.0: BAR 8: can't allocate resource
>>>> pci 0000:00:04.0: BAR 9: can't allocate resource
>>>>
>>>> I've seen this problem discussed in the archives and couldn't find what
>>>> looked like a fix. I WAS able to fix this by loading dock, pci_slot,
>>>> pci_hotplug and acpiphp and appending pci=assign-busses. However since
>>>> then I have run a package update to kernel 2.6.27.10 and I am once again
>>>> getting the same problem even with the same modules and parameters. I
>>>> have since tried appending irqpoll, pci=bios, pci=routeirq and acpi=off
>>>> with no success. I have even rolled back my kernel to 2.6.27 (and the
>>>> headers and a few other packages) setup my system the way it was setup
>>>> before to the best of my knowledge but I still can't get the PCI card
>>>> working again. Another subtle change must be responsible.
>>>>
>>>> Certain PCI devices in the dock are working such as the Cardbus slots...
>>>> but I could care less about them... is there a way I could tell the
>>>> kernel to prioritize the video card and sacrifice Cardbus slots first if
>>>> it can't allocate enough resources? Also my lspci output shows a large
>>>> gap 01:00.0 to 06:00.0 so some part of my system must have expected
>>>> other devices in that range. When I had the video card working it was
>>>> 02:00.0. I have tried changing the four IRQ numbers in the BIOS but this
>>>> is pointless at best and sometimes causes my soundcard to be disabled.
>>>> My dmesg, lspci and (trimmed) kernel config are pasted:
>>>>
>>>> dmesg: http://pastebin.com/f3ae15a58
>>>> lspci: http://pastebin.com/f5d7dee6e
>>>> .config: http://pastebin.com/fb925760
>>>>
>>>> I'm hoping for a solution that doesn't require recompiling the kernel
>>>> but I definitely would if that's necessary. In any event I'll be much
>>>> more vigilant about system updates if I get this working again.
>>>> Thank-you very much for your time.
>>>>
>> Can you post the output of lspci -vvv somewhere as well after trying 2.6.28?
>> 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;
>>
>> switch (bus->self->class>> 8) {
>>
>
> Jesse, I think this change is doing the same thing as
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8fa5913d54f3b1e09948e6a0db34da887e05ff1f
> which was reverted by
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=12c22d6ef299ccf0955e5756eb57d90d7577ac68
> because of
> http://bugzilla.kernel.org/show_bug.cgi?id=10080
> http://marc.info/?l=linux-kernel&m=120620382316329&w=2
> http://marc.info/?l=linux-kernel&m=120653981716729&w=2
>
> It definitely seems like the right thing to do but it apparently
> breaks stuff on systems with oddball transparent bridges.
>
> Gary
>
>
The output of lspci -vvv is here http://pastebin.com/f126dc794 and it is
exactly the same on 2.6.27.10 and 2.6.28. I noticed various Thinkpad
models besdies Subsystem. They are all very close to mine but not
exactly A22m. Could this mean I need to tweak the DSDT file?
Should I try the above patch at the risk of having to use a custom
kernel for the rest of my life or do you think there's a way to fix this
without breaking other systems?
On Thursday 08 January 2009 01:26:38 pm Jesse Barnes wrote:
> > On Thursday 08 January 2009, Connor Behan wrote:
> > > Hello, I am trying to use two video cards. One is the built in ATI Rage
> > > Mobility M3 AGP card which drives the screen of my laptop (Thinkpad a22m
> > > 2628-S1U if that matters), the other is the ATI Radeon X1550 PCI card in
> > > the Thinkpad Dock II which is supposed to drive an external monitor.
> > > X1550 is a PCI-E chipset but my card is a PCI card with an onboard PCI
> > > to PCI-E bridge. I first tried this with kernel 2.6.27 as packaged by
> > > Archlinux and got the following startup errors:
> > >
> > > pci 0000:00:04.0: BAR 7: can't allocate resource
> > > pci 0000:00:04.0: BAR 8: can't allocate resource
> > > pci 0000:00:04.0: BAR 9: can't allocate resource
The 00:04.0 bridge starts out with relatively small windows. From
http://pastebin.com/f3ae15a58:
181. pci 0000:00:04.0: transparent bridge
182. PCI: bridge 0000:00:04.0 io port: [0, fff] ("BAR 7")
183. PCI: bridge 0000:00:04.0 32bit mmio: [0, fffff] ("BAR 8")
184. PCI: bridge 0000:00:04.0 32bit mmio pref: [0, fffff] ("BAR 9")
but by here:
285. pci 0000:00:04.0: PCI bridge, secondary bus 0000:0a
286. pci 0000:00:04.0: IO window: 0x4000-0x4fff
287. pci 0000:00:04.0: MEM window: 0x40000000-0x47ffffff
288. pci 0000:00:04.0: PREFETCH window: 0x00000048000000-0x0000004fffffff
the windows have been assigned and the MEM and PREFETCH ones enlarged.
I don't know enough to reconcile this with the "can't allocate resource"
messages, which happen in between, at line 247.
> > > ... Also my lspci output shows a large
> > > gap 01:00.0 to 06:00.0 so some part of my system must have expected
> > > other devices in that range. When I had the video card working it was
> > > 02:00.0.
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?
> 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?
> Since in your case it looks like it's incorrectly causing some of your other
> resources to be disabled:
>
> pnp 00:02: io resource (0x22-0x22) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff), disabling
> pnp 00:02: io resource (0x92-0x92) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff), disabling
> pnp 00:02: io resource (0xb2-0xb3) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff), disabling
> pnp 00:0a: io resource (0x2e-0x2f) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff), disabling
I don't think this would cause the 00:04.0 resource allocation
failures, but it seems wrong. It looks like another case of the
PCI BARs just not being initialized. The PNP resources look fine,
and we shouldn't disable them in this case.
Bjorn
On Fri, Jan 09, 2009 at 03:30:57PM -0700, Bjorn Helgaas wrote:
> On Thursday 08 January 2009 01:26:38 pm Jesse Barnes wrote:
> > > On Thursday 08 January 2009, Connor Behan wrote:
> > > > Hello, I am trying to use two video cards. One is the built in ATI Rage
> > > > Mobility M3 AGP card which drives the screen of my laptop (Thinkpad a22m
> > > > 2628-S1U if that matters), the other is the ATI Radeon X1550 PCI card in
> > > > the Thinkpad Dock II which is supposed to drive an external monitor.
> > > > X1550 is a PCI-E chipset but my card is a PCI card with an onboard PCI
> > > > to PCI-E bridge. I first tried this with kernel 2.6.27 as packaged by
> > > > Archlinux and got the following startup errors:
> > > >
> > > > pci 0000:00:04.0: BAR 7: can't allocate resource
> > > > pci 0000:00:04.0: BAR 8: can't allocate resource
> > > > pci 0000:00:04.0: BAR 9: can't allocate resource
>
> The 00:04.0 bridge starts out with relatively small windows. From
> http://pastebin.com/f3ae15a58:
>
> 181. pci 0000:00:04.0: transparent bridge
> 182. PCI: bridge 0000:00:04.0 io port: [0, fff] ("BAR 7")
> 183. PCI: bridge 0000:00:04.0 32bit mmio: [0, fffff] ("BAR 8")
> 184. PCI: bridge 0000:00:04.0 32bit mmio pref: [0, fffff] ("BAR 9")
Could the "fff" mean the window was incorrectly disabled by BIOS?
One of the public IBM PCI-X bridge docs says:
Address bits 11:0 are assumed to be x`FFF' for the limit address.
Looks like 0 was written to both Base and Limit Registers for all
three resources. IIRC, BIOS is supposed to write ~0 to the limit
register in order to disable resource routing.
grant
>
> but by here:
>
> 285. pci 0000:00:04.0: PCI bridge, secondary bus 0000:0a
> 286. pci 0000:00:04.0: IO window: 0x4000-0x4fff
> 287. pci 0000:00:04.0: MEM window: 0x40000000-0x47ffffff
> 288. pci 0000:00:04.0: PREFETCH window: 0x00000048000000-0x0000004fffffff
>
> the windows have been assigned and the MEM and PREFETCH ones enlarged.
> I don't know enough to reconcile this with the "can't allocate resource"
> messages, which happen in between, at line 247.
>
> > > > ... Also my lspci output shows a large
> > > > gap 01:00.0 to 06:00.0 so some part of my system must have expected
> > > > other devices in that range. When I had the video card working it was
> > > > 02:00.0.
>
> 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?
>
> > 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?
>
> > Since in your case it looks like it's incorrectly causing some of your other
> > resources to be disabled:
> >
> > pnp 00:02: io resource (0x22-0x22) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff), disabling
> > pnp 00:02: io resource (0x92-0x92) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff), disabling
> > pnp 00:02: io resource (0xb2-0xb3) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff), disabling
> > pnp 00:0a: io resource (0x2e-0x2f) overlaps 0000:00:04.0 BAR 7 (0x0-0xfff), disabling
>
> I don't think this would cause the 00:04.0 resource allocation
> failures, but it seems wrong. It looks like another case of the
> PCI BARs just not being initialized. The PNP resources look fine,
> and we shouldn't disable them in this case.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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
Linus Torvalds wrote:
> 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
>
I was about to say that the kernel where this worked once doesn't allow
this to work again. I downgraded to 2.6.27 and got the same problem. But
then I also downgraded udev, mkinitcpio, lilo, device-mapper, pciutils
and hwdetect and reset the defaults on my BIOS and took out
pci=assign-busses and then the card started working.
dmesg: http://pastebin.com/m68dd0ce
lspci: http://pastebin.com/m4c01d354
It's quite a bit different from when I remember it working the other
time. The errors on BARs 7, 8 and 9 still show up and the card is on bus
09. However after I did this I updated all those packages to the newest
versions except I did so one at a time not all at once. Now I'm up to
date and still have this card working. So I'm sorry to bother you with
this, the kernel does not need to be patched for this at all. It's
either a BIOS problem or a distro problem caused by updating too many
packages at once. Either way it's fixed now. Thanks alot.
On Tue, 13 Jan 2009, Connor Behan wrote:
>
> I was about to say that the kernel where this worked once doesn't allow this
> to work again. I downgraded to 2.6.27 and got the same problem. But then I
> also downgraded udev, mkinitcpio, lilo, device-mapper, pciutils and hwdetect
> and reset the defaults on my BIOS and took out pci=assign-busses and then the
> card started working.
Ok, can you now try to upgrade just the kernel? IOW, it would be good to
try to figure out what it is that triggers this problem.
> dmesg: http://pastebin.com/m68dd0ce
> lspci: http://pastebin.com/m4c01d354
Yes, now I see a new bridge:
08:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode])
and behind this bridge is this:
09:00.0 VGA compatible controller: ATI Technologies Inc RV505 [Radeon X1550 Series] (prog-if 00 [VGA controller])
09:00.1 Display controller: ATI Technologies Inc RV505 [Radeon X1550 Series] (Secondary)
> It's quite a bit different from when I remember it working the other time. The
> errors on BARs 7, 8 and 9 still show up and the card is on bus 09.
Yup. It's all ok.
> However after I did this I updated all those packages to the newest
> versions except I did so one at a time not all at once. Now I'm up to
> date and still have this card working. So I'm sorry to bother you with
> this, the kernel does not need to be patched for this at all. It's
> either a BIOS problem or a distro problem caused by updating too many
> packages at once. Either way it's fixed now. Thanks alot.
Well, your dmesg is now from a 2.6.27 kernel, so I'd like to double-check
and verify that upgrading the kernel really works now. It does sound like
some non-kernel-related issue, but still..
Linus
Linus Torvalds wrote:
> Well, your dmesg is now from a 2.6.27 kernel, so I'd like to double-check
> and verify that upgrading the kernel really works now. It does sound like
> some non-kernel-related issue, but still..
>
>
Oops I forgot that 2.6.28 was still in testing. I have enabled testing
again and everything still works on 2.6.28 so I think this was a BIOS issue.
2.6.28 dmesg: http://pastebin.com/m3e9bc913
2.6.28 lspci: http://pastebin.com/m3cb8112d