[PlanetCCRMA] Re: [PlanetCCRMANews] added: new edge kernels for fc2/3

[Fernando Lopez-Lezcano]

On Tue, 2005-03-22 at 19:49, Shayne O'Connor wrote:
> Fernando Lopez-Lezcano wrote:
> 
> >No, not "0' certainly :-)
> >You can run this:
> >  /etc/rc.d/init.d/rtirq status
> >that will print the priority of the interrupt request handlers, I think
> >think the second down from the top should be your soundcard (check to
> >see which interrupt it is using by doing "cat /proc/interrupts/"). I
> >think the best option would be to use a slightly lower priority than
> >that (so that first to run is the interrupt handler and then jack). 60
> >should be close. 
> >  
> >
> here's the output for rtirq:
> 
>   PID CLS RTPRIO  NI PRI %CPU STAT COMMAND
>   277 FF      80  -5 120  0.0 SW<  IRQ 8
>   879 FF      60  -5 100  0.1 SW<  IRQ 22
>   952 FF      60  -5 100  0.0 SW<  IRQ 20
>   927 FF      59  -5  99  0.0 SW<  IRQ 21
>   375 FF      50  -5  90  0.0 SW<  IRQ 1
>    20 FF      49  -5  89  0.0 SW<  IRQ 9
>   298 FF      49  -5  89  0.0 SW<  IRQ 12
>   334 FF      46  -5  86  0.0 SW<  IRQ 14
>   336 FF      45  -5  85  0.0 SW<  IRQ 15
>  1882 FF      40  -5  80  0.0 SW<  IRQ 7
>  2054 FF      39  -5  79  0.0 SW<  IRQ 6
>  3447 FF      38  -5  78  0.2 SW<  IRQ 19
>  3698 FF      37  -5  77  0.1 SW<  IRQ 17
> 
> and cat /proc/interrupts:
> 
>            CPU0      
>   0:    1743956    IO-APIC-edge  timer  0/43956
>   1:        410    IO-APIC-edge  i8042  0/410
>   7:          2    IO-APIC-edge  parport0  0/0
>   8:          1    IO-APIC-edge  rtc  0/1
>   9:          0   IO-APIC-level  acpi  0/0
>  12:     152827    IO-APIC-edge  i8042  160/52826
>  14:      18240    IO-APIC-edge  ide0  44/18240
>  15:        477    IO-APIC-edge  ide1  0/477
>  17:     121688   IO-APIC-level  EMU10K1  77/21688
>  19:     106598   IO-APIC-level  nvidia  7/6598
>  20:          0   IO-APIC-level  ohci_hcd  0/0
>  21:          0   IO-APIC-level  ohci_hcd  0/0
>  22:     175682   IO-APIC-level  ehci_hcd, eth0  178/75682
> NMI:          0
> LOC:    1738855
> ERR:          0
> MIS:          0
>
> as you can see, my soundcard is *last* rtirq list ... isn't irq 17 the
> worst possible irq for the soundcard to be on? geez, could mean another
> trip inside the computer ...

Strange. This could be a bug in the way rtirq orders the interrupts. The
priority order is determined by rtirq, not by the internal ordering
within the BIOS and won't be changed by swapping cards around (unless
that un-triggers the problem in rtirq). 

You could try to change the priority of irq17 and see if that affects
realtime behavior. You need to use the chrt command, as in (for example
above, this will probably change if you reboot):
  chrt -f -p 61 3698
(the last number is the pid of the irq handler for irq17)

Rui: what do you think? I have not looked at the script yet...

> just in general, and i know there's heaps written on this subject but
> i'm not sure how current it is, should i use ACPI (or is that APIC?) or
> not? i currently have acpi daemon loading at start-up too ... or is this
> supposed to be something that rtirq takes care of?!

It is something differnet. ACPI is the power management system
(successor of APM). APIC is, I think, an IC that handles interrupts? I'm
not too sure about the last one. Both can affect how interrupts are
handled but that is separate from the optimization of priorities that
rtirq does.

-- Fernando