On 11/27/05, Lee Revell <rlrevell@email-addr-hidden-job.com> 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
Received on Mon Nov 28 04:15:06 2005
This archive was generated by hypermail 2.1.8 : Mon Nov 28 2005 - 04:15:07 EET