[linux-audio-user] Is everyone sick of interrupts yet?

Mark Knecht mknecht at controlnet.com
Tue Sep 28 12:57:15 EDT 2004


Mark Knecht wrote:
> brad stafford wrote:
> 
>> I just tonight switched from the Planet CCRMA RH9 to FC1. The install
>> was purely from the CDROMs dated 4/25/2004.
>>
>> I've seen all the latest posts about interrupts and did the required
>> reading on the internet. I really managed to get RH9 cleaned up but in
>> FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
>> running an AMD Barton 2.6 with 5 PCI slots. The question is what the
>> heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
>> get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
>> have ACPI turned off as a service but don't have a "disable" option in
>> the BIOS. I did turn off USB support in the BIOS.
>>
>> Is 16 like the equivalent of IRQ 3 since it's following 15?
>>
>> [brad at mars brad]$ cat /proc/interrupts
>>            CPU0
>>   0:      81690    IO-APIC-edge  timer
>>   1:         75    IO-APIC-edge  keyboard
>>   2:          0          XT-PIC  cascade
>>   8:          1    IO-APIC-edge  rtc
>>   9:          0   IO-APIC-level  acpi
>>  12:        836    IO-APIC-edge  PS/2 Mouse
>>  14:      10789    IO-APIC-edge  ide0
>>  15:        735    IO-APIC-edge  ide1
>>  16:          0   IO-APIC-level  ICE1712
>>  22:         21   IO-APIC-level  eth0
>> NMI:          0
>> LOC:      81633
>> ERR:          0
>> MIS:          0
>>
>> I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
>> 2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
>> capabilities.
>>
>> Thanks, Brad.
>>
>>
> Brad,
>    First I see no reason for you to change anything. If there's no 
> problem to fix, then why make a problem?
> 
>    Interrupts, in your case, are based on the APIC model. You machine 
> has an APIC (Advanced Programmable Interrupt Controller) as well as one 
> or more IO-APIC chips, so it supports more than the old style 15 
> interrupts. This is not a problem. It should be an advantage, if 
> everything is set up correctly.
> 
>    My input would be to go with the flow. If one of these days you find 
> that you are getting worse performance, be it xruns or something else, 
> then come back and let's look at the setup of the machine. Until then, 
> be happy. It looks like the results are quite good, right?!?
> 
> Cheers,
> Mark
> 

One last little sickening detail I forgot to add before. Sorry for doing 
it now.

In the older 'compatibility model' we knew the 'prioity of the interrupt 
from the interrupt number: 0,1,8,9,10,11,12,13,14,15,3,4,5,6,7. It was 
hardwired.

In the newer 'APIC' model all we know is the interrupt number, not the 
priority. There is a secondary routing table that maps the interrupt 
priority using a vector. The table is visible in dmesg on my machines. 
It probably is on yours also. The meaning of the table is obscure and 
has been covered here before. The 'unfortunate' aspect of the table is 
that there are no generally avaialble tools to allow a system 
administrator to modify the vectors and hence change the priorities of a 
given hardware device. Not sure that matters to most people. I would be 
happier having that capability and hope it will appear one day.

Sorry for chiming in again.

- Mark




More information about the Linux-audio-user mailing list