Subject: Re: [linux-audio-user] APIC
From: Clemens Ladisch (clemens_AT_ladisch.de)
Date: Thu Jan 22 2004 - 18:11:15 EET
Mark Knecht wrote:
> > .... 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, ...
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.
> 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
This archive was generated by hypermail 2b28 : Thu Jan 22 2004 - 18:12:18 EET