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

[Grant Grundler <grundler@parisc-linux.org>]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html