mknecht at controlnet.com
Thu Jan 22 15:04:41 EST 2004
Hi. Thanks for the response. It's very helpful and good information.
Since I think there is still some differences between your software and my
hardware points of view so I'll continue to ask a few questions and document
my points below. No *major* disagreements with what you wrote, maybe one
minor one at the very end. Mostly this is still clarification and
> Lower-priority interrupts don't automatically get suppressed, or much
Possibly true, or should be if software is designed right.
> The priority is simply used to choose between several
> interrupts occuring at the same time, which happens almost never.
Speaking as a hardware designer who has worked on chipset and many different
I/O controller technologies (SCSI, EIDE, Ethernet, 1394, USB and legacy) I
can assure you that this is not always true. None the less, it only takes
one delay to create an xrun and blow a live recording.
> > 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
;-) OK, now it's extremely well known fact that I'm not a programmer. Why
would you think there was *any* chance I'd ever written a driver? ;-)
(Though I have managed Windows SCSI driver programmers and have some
> > 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
> Indeed, IRQ22 does have the highest priority in your system.
> (BTW, 17 = 0x11)
It was not marked as such in my system. 17 was marked 0x00. None the less,
it wouldn't change thing much. (0x00 vs. 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
Ah! Ok, that's good info although my system sort of makes it look like LOC:
and IRQ0: are the same thing since they always have the same number of
> 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.)
OK, so then the real question is how does APIC mode change the relationship
between all of the older 'legacy' devices and the PCI bus. It's not
difficult to show, so let's map this out, old style vs. APIC style. I'll
show the highest priority interrupts at the top of the list (legacy style)
since I expect that someone like Jan Depner might be reading this and
possibly someday it would make it onto his pages. I'll add an APIC column
for what I think I'm reading in your words and then we'll correct my
misunderstanding or your POV.
Legacy Function APIC Style
IRQ16 PCI slots??????
IRQ0 Timer Timer
IRQ1 Keyboard Keyboard
IRQ2 Cascade->IRQ8-15 Cascade
IRQ8 RTC RTC
IRQ12 PS/2 Mouse PS/2 Mouse
IRQ13 (Old FPU)
IRQ14 IDE0 IDE0
IRQ15 IDE1 IDE1
IRQ3 Com2/PCI Com2
IRQ4 Com1/PCI Com1
IRQ5 Parallel/PCI Parallel
IRQ6 Floppy Floppy
IRQ7 Printer/PCI Printer
Now, my point is that I do not think/believe/agree that the PCI slots are
intended to have higher priority than the Timer or the keyboard. I could
certainly be wrong, but to me it doesn't make sense. On the other hand, I
could certainly agree with the idea that all of the APIC stuff could link in
around IRQ9 (like it does on an XP machine) with a second level of priority
assigned by the vector in the table.
I am just not sure which you are suggesting is true.
Notes for casual readers:
a) I add PCI to IRQs 3, 4, 5 & 7 from personal experience. Not all
motherboards support this.
b) I do not show onboard devices that may share interrupts, such as USB, USB
2.0 or 1394. Consult your motherboard manual or 'lspci -v' for more info on
your system. Manufacturers are free to rearrange most anything if they don't
care about DOS compatibility.
c) VGA interrupts are often shared with a PCI slot. On many systems the
interrupt number can be reassigned. On many of my legacy systems I run it at
> 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.
I think you wouldn't say this if you placed an active Gigabit Ethernet
adapter at interrupt 22 and a sound card at interrupt 21. Maybe that's not
What about a 10/100 Ethernet at 22, a 1394 adapter at 21, maybe a USB
controller at 20 and your sound card at 19. Over time my experience is that
you will see xruns. Change the order to sound card at 22 and you see fewer
xruns. Or that's my experience.
With best regards to you too!
More information about the Linux-audio-user