Transparent bridges (a. k. a. HUB-to-PCI bridges)?

[Wilkinson, Alex]

Trying to understand your nomenclature John, so that I can follow this thread.

Can you please elaborate on the following .... please ;-\

1. PCI bridges 
   - Host-PCI
   - PCI-PCI

2. OOPish device object (device_t) ? 

3. $PIR table 

 - aW
   


0n Tue, Nov 23, 2004 at 01:43:22PM -0500, John Baldwin wrote: 

> On Tuesday 23 November 2004 12:26 pm, Jung-uk Kim wrote:
> > While I was booting Linux, I saw a 'transparent bridge' from dmesg and
> > started digging up because I was fighting against 'interrupt
> > storming' and 'stray IRQ' problems with the latest Intel chipsets
> > recently and I had a feeling that it's somehow related.
> >
> > http://lxr.linux.no/source/drivers/pci/probe.c?v=2.6.8.1#L195
> > http://lxr.linux.no/source/arch/i386/pci/fixup.c?v=2.6.8.1#L192
> > http://lxr.linux.no/source/arch/i386/pci/irq.c?v=2.6.8.1#L870
> > http://lxr.linux.no/source/arch/i386/pci/irq.c?v=2.6.8.1#L1017
> >
> > But I don't see any special treatment in FreeBSD's PCI driver.
> >
> > 1.  Is this relevant for FreeBSD?
> > 2.  Is this related to the problems (esp. SMP)?
> 
> First of all, I have no idea what type of interrupt routing problems you are 
> having, but as for the above:
> 
> FreeBSD uses a much simpler way of managing PCI interrupt routing.  In 
> FreeBSD, each hardware device (including PCI bridges (whether Host-PCI or 
> PCI-PCI) and PCI busses) have an OOPish device object (device_t) associated 
> with them.  You can see the tree structure via 'devinfo'.  The way FreeBSD 
> implements interrupt routing is that each PCI bridge driver provides a method 
> for determining the IRQ associated with a given bus/device/pin tuple.  (The 
> bus is implicit since each bridge only handles requests for its immediate 
> downstream bus.) In order to make use of the several different ways of 
> determining interrupt routing, there are several different PCI bridge drivers 
> for both Host-PCI and PCI-PCI bridges.  For example, there are ACPI Host-PCI 
> and PCI-PCI bridge drivers that will route interrupts using the _PRT table 
> objects provided by ACPI for busses in ACPI's namespace.  Also, there are 
> PCIBIOS bridge drivers to handle routing for the non-ACPI non-APIC case using 
> the information in the $PIR table.  Similarly, for the non-ACPI APIC case, 
> there are MP Table bridge drivers to route interrupts for busses that are 
> listed in the MP Table.  If a PCI-PCI bridge is not enumerated in ACPI space 
> on an ACPI system or is not listed in either the $PIR (non-APIC) or MP Table 
> (APIC) on a non-ACPI system, then the bridge will be probed via the simple 
> PCI-PCI bridge driver which does the standard barber-pole swizzle to route 
> interrupts based off the intpins on the bridge device's upstream connection.  
> Thus, for "transparent" bridges not listed in the MP Table, the MP Table 
> driver won't attach and it will fall back to the simple PCI-PCI bridge driver 
> and just work.
> 
> Now, back to your original problem: what type of interrupt problems are you 
> having?
> 
> -- 
> John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>