Subject: Re: [linux-audio-user] APIC is bad?
From: Malcolm Baldridge (linux-audio_AT_paypc.com)
Date: Fri Jul 16 2004 - 04:07:50 EEST
> 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):
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
-- A focus on Quality.
This archive was generated by hypermail 2b28 : Fri Jul 16 2004 - 04:12:12 EEST