Still IRQ routing problems with bridged devices.
jhb at FreeBSD.org
Fri Jan 2 13:30:51 PST 2004
On 02-Jan-2004 Bernd Walter wrote:
> On Fri, Jan 02, 2004 at 02:19:53PM -0500, John Baldwin wrote:
>> On 01-Jan-2004 Bernd Walter wrote:
>> > On Thu, Jan 01, 2004 at 10:12:23AM -0700, M. Warner Losh wrote:
>> >> In message: <20040101155100.GF11668 at cicely12.cicely.de>
>> >> Bernd Walter <ticso at cicely12.cicely.de> writes:
>> >> : On Wed, Dec 31, 2003 at 10:22:30PM -0700, M. Warner Losh wrote:
>> >> : > In message: <20040101013224.GC11668 at cicely12.cicely.de>
>> >> : > Bernd Walter <ticso at cicely12.cicely.de> writes:
>> >> : > : The board is an old Asus T2P4 with 3 bridged cards and $PIR table.
>> >> : > : All IRQs behind bridges get bogusly IRQ4 instead of the right ones.
>> >> : > : Is this only a problem on some boards or do we have a general irq
>> >> : > : routing problem with bridges?
>> >> : >
>> >> : > It is a problem with some bridges and PCI BIOS interrupt routing.
>> >> :
>> >> : The intline registers are correct - that's what used to run since years.
>> >> : What has the kind of bridge to do with it?
>> >> just what the code does :-)
>> > But bridges are handled generic so why would only some bridges show
>> > this problem?
>> > The bridges are 21050 types btw.
>> Sounds like a BIOS bug. If a bridge isn't listed in the $PIR, we
>> use the barber-pole swizzle to route across it. However, that is
> It can't know about my bridges because all of them are on cards and
> they wouldn't won't fit with just 7 entries.
Ok, if they are on cards, that is correct.
>> technically only defined for bridges on add-in cards. The only
>> way we can tell if a bridge is on an add-in card is if it is not
>> listed either in ACPI's namespace with a _PRT or it is not listed
>> in the $PIR. Part of teh problem is that we shouldn't be using
> It's not that simple.
> The chips behind the bridges are layed out to all use INTA on the
> primary bus, but INTA is correctly routed for non-bridged cards.
> I have no clue about $PIR and therefor have no idea where irq4 comes
> from - any pointer to $PIR documents are welcome.
Erm, according to the PCI spec, the devices behind the bridges on the
add-in cards will swizzle their interrupts. Thus, device 8.0 will
use INTA on the add-in card's connect, 9.0 will use INTB for its
INTA, etc. We use the $PIR to then figure out what IRQ to use for
INT[ABCD] on that slot as appropriate. Thus, it would work something
1) device 1.8.0 wants to route INTA so it asks the bridge for the IRQ
2) the bridges translates that into INTA on itself, and asks its parent
for a route to INTA at its slot (say 0.2.0).
3) the host bridge lookes up 0.2.0 INTA in the $PIR, chooses an IRQ from
the possible list (defaults to just using first IRQ) and returns it.
This step should be skipping IRQ 4 adn using IRQ 10 or 11 instead
For device 1.9.0, the bridge translates that into 0.2.0 INTB. Hope that
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
More information about the freebsd-current