[linux-audio-user] APIC

Clemens Ladisch clemens at ladisch.de
Thu Jan 22 11:11:15 EST 2004


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





More information about the Linux-audio-user mailing list