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

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

Message-ID: <496BFFAA.3000707@gmail.com>
Date:	Mon, 12 Jan 2009 21:42:50 -0500
From:	Connor Behan <connor.behan@...il.com>
To:	Grant Grundler <grundler@...isc-linux.org>
CC:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	Linux PCI <linux-pci@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Gary Hade <garyhade@...ibm.com>
Subject: Re: Can't allocate resources for PCI video card behind bridge

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.
--
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/