lkml.org 
[lkml]   [2009]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Can't allocate resources for PCI video card behind bridge
    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


    \
     
     \ /
      Last update: 2009-01-10 21:11    [W:0.031 / U:29.896 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site