27 Nov
2005
27 Nov
'05
6:01 p.m.
On Sun, 2005-11-27 at 16:51 -0500, Paul Davis wrote:
On Sun, 2005-11-27 at 15:07 -0500, Lee Revell wrote:
Ah, OK. I should have prefaced my statement with "from the Linux
kernel's perspective".
Anyway my point (that the OP is not going to improve his PD performance
by twiddling with the interrupt controller) remains valid.
Lee
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 :)