27 Nov
2005
27 Nov
'05
5:12 p.m.
On 11/27/05, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2005-11-27 at 11:03 -0800, Mark Knecht wrote:
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.
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.
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