On Sun, 2005-11-27 at 15:07 -0500, Lee Revell 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. 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
