On 11/27/05, Lee Revell <rlrevell@xxxxxxxxxxx> wrote: > On Sun, 2005-11-27 at 11:03 -0800, Mark Knecht wrote: > > OK, this 'priority' is the Linux kernel's priority. The 'priority' I > > was speaking of was the actual hardware priority. They are different > > things. > > > > In the older PIC when an ISR was entered all lower hardware 'priority' > > IRQ are blocked until the ISR tells the PIC it is ready to release. > > That is the numerical list I gave earlier. In that list is something > > at IRQ14 starts and doesn't release then all interrupts of lower > > hardware priority (15,3,4,5,6,7) will not happen. > > > > Wrong. PIC or APIC, interrupts do not delay other interrupts in this > way. If a disk interrupt happens on IRQ14 then a soundcard interrupt on > IRQ5 fires immediately after then the disk interrupt handler will be > interrupted by the sound card interrupt handler. That's why they are > called interrupts! This is why I keep trying to explain that there is > no "priority" relationship between interrupts. Sorry, but while this is correct at the software level it is, unfortunately, completely incorrect at the hardware level. While I am not a programmer and do not know myself how to do it, if I write (as an example only) an ISR that simply turns off interrupts and goes into a loop, then since interrupts are off no other interrupt will get through and since the ISR is in a loop it will never return. The machine is locked and you're hung. While I do not suggest that this example is anything other than pathological, it demonstrates the problem. > > In the above scenario if BOTH devices were sharing IRQ14 then the second > interrupt handler WOULD be delayed until the first finished. Correct and agreed to. > > The ability to prioritize interrupts with the -rt kernel is useful > because interrupts can be prevented from interrupting USERSPACE code. Cool! > > I think people might be confused because Windows has a notion of the > interrupt priority level? This I'm not sure of. Thanks, Mark > > Lee > >
