[Asterisk-Users] PCI Problems

[Andrew Kohlsmith]

On Saturday 27 May 2006 04:36, Rob Lith wrote:
> How does I/O APIC fit into this IRQ management?

Pretty much every single modern system (I'm counting from about P3 onward) 
does not have a "standard" interrupt controller in the old i8259 sense.  
Pentium/P2/some P3 systems all had the controller embedded in the motherboard 
chipset, but the interrupt controller was pretty much the same old pair of 
i8259s, with PIC#2 daisy-chained to PIC#2 on interrupt #2.

The IO-APIC was a change in the way interrupts were done in order to try and 
eliminate the problem of IRQ starvation that's been a problem since the first 
person tried to install additional hardware in the old XT.  Instead of 
limiting yourself to just 15 IRQs, the IO-APIC can have dozens of IRQs.  
Every PCI slot has its INTA# line routed to a separate physical IRQ line on 
the IO-APIC.  Every PCI peripheral onboard (disk controllers, video, LAN, you 
name it) is run to its own dedicated IRQ line on the IO-APIC.  Nothing 
actually shares the IRQ anymore.

Some software/drivers/etc can't handle this new mode (they haven't been coded 
or modified to accept the concept of more than 15 IRQs), so the IO-APIC has 
an emulation mode which mangles the interrupt lines in such a way as to 
present the standard old 15 IRQs.  This is XT-PIC emulation.

If your system IO-APIC isn't screwy and you're running a modern OS with good 
support for your non-screwy IO-APIC, then running the IO-APIC in its native 
mode is generally the best idea.  Whenever your IRQ is fired, you are pretty 
damn sure that the IRQ was for you.  Less latency because there's only one 
driver checking the hardware for an interrupt condition, less potential 
screwup for drivers which do this wrong...  

Some motherboards have so many peripherals that they still do put more than 
one peripheral interrupt on one IRQ line, but it's FAR LESS LIKELY that you 
are sharing interrupts on a modern system running its IO-APIC in native mode.

Make sense?

-A.