On 11/27/05, Lee Revell <rlrevell@xxxxxxxxxxx> wrote: > On Sun, 2005-11-27 at 13:12 -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. > > It does not demonstrate a real world problem. Agreed. > If this were to happen it > would be a grave kernel bug. I do not think so. The Linux kernel doesn't have a bug if the hardware interrupt to the processor is never asserted. This is what happened on the PIC if a lower priority interrupt came along at the wrong time. > > In the Linux kernel only drivers that register their ISR with > SA_INTERRUPT block out ALL other interrupts until they complete. > Currently the ALSA drivers and system timer do this as the handling of > those interrupts has RT constraints, and the handlers execute quickly > anyway. > > Lee I agree that things are in pretty good shape as far as Linux ISR's seem to go, but that was not always the case... Cheers, Mark
