> I rebuilt the latest Fedora 2 kernel update to enable preempt and > IO-APIC. I'm not yet sure about preempt, but IO-APIC has been > acting weird. > It gave me more interrupts (up to 21 instead of 15), but the devices > were distributed suboptimal. How odd. Usually with a real APIC, the interrupts get distributed so they are uniquely assigned to devices. Maybe your BIOS is weird, or maybe it needs a "Reset PnP data", or the "PnP OS Installed" option set to OFF. > Without APIC, the nvidia module was alone on its own interrupt, the > EMU10K1 was alone, the ide and eth modules were on separate interrupts, > etc. Quite ok. Sounds like you didn't have a problem to fix. Why did you enable APIC? On most of my systems with real APICs, I don't get a unique assignment of IRQs unless I enable APIC support. Note! ACPI eats an IRQ (9) almost always. > BTW, anyone has any measurements on how bad it is to put essential > devices on the same interrupt? (in terms of xruns) It's not the "really bad thing" it used to be, however it does take additional time to determine the source of the interrupt. PCI was designed around a model where IRQ sharing was an important part of the spec. It's not the total-brokenness in the way ISA-era IRQ conflicts were. Keep in mind also, that the IRQ priority is a bit strange. It goes (from highest to lowest priority): 0,1,2(9),10,11,12,13,14,15,3,4,5,6,7,8 IRQ 2 is exactly the same as IRQ 9. In an 8-bit ISA card, it would termed 2, and in a 16-bit ISA/PCI slot it's 9. Ideally, you want the least-latency-sensitive devices on the lower priority interrupts and the most latency-sensitive on the higher priority interrupts. Low-latency linux kernels generally get "out" of top-halves of their interrupt handlers pretty quickly, thus allowed the servicing of another IRQ pretty quickly. =MB= -- A focus on Quality.
