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
