Re: [linux-audio-user] IRQ settings and low latency

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] IRQ settings and low latency
From: Mark Knecht (markknecht_AT_comcast.net)
Date: Sat Mar 13 2004 - 18:41:20 EET


On Thu, 2004-03-11 at 12:15, Greg Jednaszewski wrote:
> At the end, it talks about setting up IRQs such that the sound card is
> at a high priority relative to other devices in the system. However,
> all the information in the doc pertains to non-APIC machines. What
> about an APIC-enabled machine?
>

Greg,
   Hi. On APIC enabled machines the story is somewhat different. OK,
it's totally different. I've poked around looking for info. I've gotten
pretty consistent answers, even if they are somewhat confusing. Clemens
and I had a discussion about this earlier. I think it's probably in the
archives if you want to go dig that up.

   The short answer is that the IRQ number doesn't have anything to do
directly with interrupt priority on an APIC machine, but its vector
does.

   First, start with dmesg more or less immediately after a boot. You'll
find a big section that looks like this:

 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 000 00 1 0 0 0 0 0 0 00
 01 001 01 0 0 0 0 0 1 1 39
 02 001 01 0 0 0 0 0 1 1 31
 03 001 01 0 0 0 0 0 1 1 41
 04 001 01 0 0 0 0 0 1 1 49
 05 001 01 0 0 0 0 0 1 1 51
 06 001 01 0 0 0 0 0 1 1 59
 07 001 01 0 0 0 0 0 1 1 61
 08 001 01 0 0 0 0 0 1 1 69
 09 001 01 0 1 0 1 0 1 1 71
 0a 001 01 0 0 0 0 0 1 1 79
 0b 001 01 0 0 0 0 0 1 1 81
 0c 001 01 0 0 0 0 0 1 1 89
 0d 001 01 0 0 0 0 0 1 1 91
 0e 001 01 0 0 0 0 0 1 1 99
 0f 001 01 0 0 0 0 0 1 1 A1
 10 001 01 1 1 0 1 0 1 1 B9
 11 001 01 1 1 0 1 0 1 1 C1
 12 001 01 1 1 0 1 0 1 1 A9
 13 001 01 1 1 0 1 0 1 1 B1
 14 000 00 1 0 0 0 0 0 0 00
 15 001 01 1 1 0 1 0 1 1 C9
 16 001 01 1 1 0 1 0 1 1 D1
 17 000 00 1 0 0 0 0 0 0 00

The first column is the hex version of what's in the /cat
/proc/interrupts table, and the last column is the vector associated
with that interrupt. The priority, as I understand it, is driven by the
highest vector number. In the table above vector 'D1' is highest, so you
look back at it's IRQ number (16 hex) convert it to decimal (22) and
look it up in the /proc/interrupts table and find that in this machine
the VIA8233 has the highest priority, followed by USB, then the ICE1712,
the radeon, and so on.

mark_AT_Wizard mark $ cat /proc/interrupts
           CPU0
  0: 308971 IO-APIC-edge timer
  1: 1891 IO-APIC-edge keyboard
  2: 0 XT-PIC cascade
  8: 2 IO-APIC-edge rtc
  9: 0 IO-APIC-level acpi
 12: 40857 IO-APIC-edge PS/2 Mouse
 14: 14236 IO-APIC-edge ide0
 15: 12 IO-APIC-edge ide1
 16: 195648 IO-APIC-level radeon_AT_PCI:1:0:0
 17: 0 IO-APIC-level ICE1712
 18: 6785 IO-APIC-level eth0
 21: 6124 IO-APIC-level usb-uhci, usb-uhci, usb-uhci
 22: 9802 IO-APIC-level VIA8233
NMI: 0
LOC: 308929
ERR: 0
MIS: 0
mark_AT_Wizard mark $

*APPARENTLY* interrupts with no vector (like the system timer) are
either not handled by the APIC system, or are just higher priority than
those with vectors. This makes sense for IRQ0 which is the system timer,
and for IRQ14 where I have no device so a vector was not assigned.

Unfortunately I know of no method to tune the system interrupt
priorities other than move cards from slot to slot until you get
something acceptable. I would like to have my AP2496 (the ICE1712) as
the highest priority device in this box but I haven't managed to make
that happen yet. The 'right' way to do it is to have an app that would
rewrite the vector table, but no app like this exists today, at least in
the user space, as far as I know.

I hope this helps answer some of your questions, and truly hope I didn't
create more confusion.

With best regards,
Mark


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Mar 13 2004 - 18:41:05 EET