27 Nov
2005
27 Nov
'05
4:49 p.m.
On Sun, 2005-11-27 at 15:07 -0500, Lee Revell wrote:
On Sun, 2005-11-27 at 11:03 -0800, Mark Knecht wrote:
wrong, at least on PIC based systems. the PIC doesn't allow the IRQ line
to the CPU to be raised by a lower priority line until the CPU has acked
the higher priority IRQ. if the CPU never resets the relevant bit on the
PIC, you can completely wedge the system. all linux kernels clear this
bit long before the interrupt handler for the device is ever invoked, so
you can be forgiven for thinking it works the way you've described :)
--p
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.