assigning interrupts

John Baldwin jhb at freebsd.org
Thu Nov 13 12:12:26 PST 2008


On Thursday 13 November 2008 11:56:31 am Jeremy Chadwick wrote:
> On Thu, Nov 13, 2008 at 04:40:03PM +0100, Joerg Sonnenberger wrote:
> > On Thu, Nov 13, 2008 at 02:40:54AM -0800, Jeremy Chadwick wrote:
> > > Otherwise, consider purchasing a motherboard that has an APIC (this is
> > > not a typo) increasing the IRQ count to 256.
> > 
> > This is wrong. The first IO-APIC gives you 8 additional interrupts to
> > the 16 ISA interrupt lines. Every additional IO-APIC gives you 24 more.
> > Most modern chipsets have one IO-APIC, at least for non-embedded
> > systems. It doesn't mean you don't get interrupt sharing though.
> 
> I think the problem is that I was thinking of local APICs, which provide
> a few hundred (I don't remember the exact number) IRQs to an I/O APIC.

It doesn't really work that way.  While local APICs do have interrupt pins, 
they are used for things like NMI or interrupt requests from the 8259As.  I/O 
APIC interrupts (and MSI interrupts) are delivered as messages to the local 
APIC.  For older APIC systems (< PII-Xeon) there was a dedicated 3-wire bus 
between the local and I/O APICs on which these messages were delivered.  For 
newer systems the APIC messages are actually passed on the main system bus.  
Part of the message contains the IDT vector to be triggered for this 
interrupt (which ranges from 0 - 255, but 0 - 31 are reserved for CPU faults 
and exceptions).  IRQ numbers are a made up cookie system that FreeBSD uses 
to number interrupt sources (pins on interrupt controllers like 8259A or I/O 
APICs, or MSI messages on PCI devices).

> Regarding "it means you can still get interrupt sharing", I'd like to
> hear more about why/how that's possible with a system sporting at least
> one I/O APIC.

The motherboard is free to tie the interrupts pins from two different PCI 
devices to a single input pin on the I/O APIC.  There is no hard requirement 
that each device gets a dedicated pin.

-- 
John Baldwin


More information about the freebsd-hackers mailing list