[linux-audio-user] APIC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I apologize in advance to all for the length of this.
I apologize in advance to anyone who isn't interested in PC internals and
optimizing DAW type machines.

- Mark

> I've looked into the Intel documentation, and it turns out I thought
> wrong, i.e., the first quoted link is right.  (But it was for an older
> Linux version which assigned vector numbers consecutively.)

You are certainly forgiven! ;-)

<SNIP>

>
> So, if Intel's explanation is correct, higher vector numbers have
> higer priority.
>
> > The table shown by Zwane is output into the system log when booting.
>
> For example, on my P4P800, dmesg says:
>
> .... IRQ redirection table:
>  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
>  00 000 00  1    0    0   0   0    0    0    00
<SNIP>
>  15 003 03  1    1    0   1   0    1    1    D9
>  16 003 03  1    1    0   1   0    1    1    E1
>  17 003 03  1    1    0   1   0    1    1    C9

Yes, E1 is the highest in this table.

>
> So, interrupt 22 (0x16) has the highest priority (vector 0xE1),
> followed by interrupts 21 and 20, etc.  (On the P4P800, these
> interrupts are assigned to the onboard 3C940 and PCI slots 5 and 4,
> respectively.)

This is what bothers me about this explanation. (Not yours, just the whole
thing overall.) If your Ethernet adapter has the highest priority, then it's
ahead of the keyboard, it's ahead of the system timer and the RTC. How can
the PC even work correctly if this is the case? (Please see section below on
IRQ's <15) Time would be drifting around and when a piece of Ethernet driver
code crashes nothing would be able to break in. Not good.

>From my A7V333-X machine. This machine works well with Jack for both the
HDSP 9652 and the Via8325. (Why is it reported as an 8233?)

mark@Wizard mark $ cat /proc/interrupts
           CPU0
  0:    6842598    IO-APIC-edge  timer
  1:        111    IO-APIC-edge  keyboard
  2:          0          XT-PIC  cascade
  8:          2    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:      12693    IO-APIC-edge  PS/2 Mouse
 14:      28464    IO-APIC-edge  ide0
 15:        598    IO-APIC-edge  ide1
 16:          3   IO-APIC-level  ohci1394
 17:       5806   IO-APIC-level  hdsp
 18:     221622   IO-APIC-level  eth0
 21:      39015   IO-APIC-level  usb-uhci, usb-uhci, usb-uhci
 22:       7783   IO-APIC-level  VIA8233
NMI:          0
LOC:    6842689
ERR:          0
MIS:          0
mark@Wizard mark $

>From dmesg this machine shows the following:
(rearranged in IRQ order (last column) for this discussion)

 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 000 00  1    0    0   0   0    0    0    00
 14 000 00  1    0    0   0   0    0    0    00
 17 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


 12 001 01  1    1    0   1   0    1    1    A9
 13 001 01  1    1    0   1   0    1    1    B1
 10 001 01  1    1    0   1   0    1    1    B9
 11 001 01  1    1    0   1   0    1    1    C1
 15 001 01  1    1    0   1   0    1    1    C9
 16 001 01  1    1    0   1   0    1    1    D1

So, IRQ22 (0x16) is my Via8235 and it rates higher priority than my timer at
IRQ0? I doubt it. Possibly higher than my HDSP at IRQ17? (0x12)

There was the part in your earlier post that said"

"When in APIC mode, there is a fixed mapping of PIRQx inputs to interrupts
above 15 (PIRQA = 16, PIRQB = 17, ...). Each of these 16 or 24+ hardware
interrupts can be routed to one of 256 software interrupt vectors."

If interrupts below 15 are used for these more traditional interrupt sources
then I can see how this could possibly work, but I need to know what set of
functions exist down there. Where, for instance, are the serial and parallel
ports and the floppy interrupts mapped in this new APIC mode?

If the above is correct, then it would be impossible to map a sound card as
having higher priority than the ide0/ide1 interrupts, wouldn't it?

>
> It would be possible to assign a different vector number to a specific
> interrupt by patching the assign_irq_vector function in
> arch/i386/kernel/io_apic.c

Cool. This *possibly* could allow one to reduce the priority of the
ide0/ide1 devices? Not sure at all.

Thanks for your time to investigate this. I think that a bit more discussion
in this area will yield some standard ways to optimize the Linux PC for
audio use.

Cheers,
Mark



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux