22 Jan
2004
22 Jan
'04
11:14 a.m.
Mark Knecht wrote:
Lower-priority interrupts don't automatically get suppressed, or much
delayed. The priority is simply used to choose between several
interrupts occuring at the same time, which happens almost never.
.... 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.
Apparently, you've never developed a driver. ;-) When any interrupt
handler crashes, Linux prints the following dreaded message after the
usual report:
| Kernel panic: Aiee, killing interrupt handler!
| In interrupt handler - not syncing
and _everything_ halts -- no interrupts, no keyboard, no Alt+SysRq.
All you can do is a hard reset and be delighted at what fsck tells
you.
... and the Via8325. (Why is it reported as an 8233?)
Because VIA didn't bother to assign different PCI IDs to its
southbridges.
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)
Indeed, IRQ22 does have the highest priority in your system.
(BTW, 17 = 0x11)
And in APIC mode, Linux doesn't use interrupt 0 for the timer (vector
0 is reserved, so interrupts 0, 20, and 23 are unused). Instead, the
local APIC timer is used (this is the "LOC:" line in
/proc/interrupts).
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?
The APIC mode affects PCI interrupts only. The so-called 'legacy'
devices still use interrupts below 16, and the mapping from device to
interrupt number doesn't change. (Actually, it can be changed, but
the configuration of the Super-I/O chip is done only by the BIOS.)
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?
The sound card (and all other PCI devices) do have a higher vector
number than the IDE interrupts, so it does have a higher priority.
But that won't help you the least if an IDE interrupt occurs before
the sound card interrupt, and does some work for several milliseconds,
and disables _all other_ interrupts during this time. Priorities
don't help you because the handler for a lower-priority interrupt can
still block all higher-priority interrupt handlers.
Well, I think all these technical details obscured the point I was
trying to make, which is that, for all practical purposes, interrupt
priorities don't matter when tuning a sound card.
Regards,
Clemens