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
