Clemens, 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 comparison. - Mark <SNIP> > > Lower-priority interrupts don't automatically get suppressed, or much > delayed. 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 > you. ;-) 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 first-person background...) <SNIP> > > > 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 <SNIP> > > 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 > /proc/interrupts). 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 interrupts. <SNIP> > > 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 IRQ255 ... IRQ16 PCI slots?????? IRQ0 Timer Timer IRQ1 Keyboard Keyboard IRQ2 Cascade->IRQ8-15 Cascade IRQ8 RTC RTC IRQ9 PCI IRQ10 PCI IRQ11 PCI/VGA 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 IRQ11. <SNIP> > > > 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 practical enough 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. > > Regards, > Clemens With best regards to you too! - Mark
