Re: [ECOS] Re: DSR stops running after heavy interrupts. Spurious Interrupt!

[Nick Garnett <nickg@ecoscentric.com>]

 Sergei Organov <osv@javad.com> writes:

> Nick Garnett <nickg@ecoscentric.com> writes:
> > "Joe Porthouse" <jporthouse@toptech.com> writes:
> [...]
> 
> >> Was there a reason why interrupt_end() should not be
> >> called on spurious interrupts?
> >
> > I guess it was an attempt to avoid doing more than the absolute
> > minimum on spurious interrupts. It looks like there is a bug in there,
> > since the scheduler lock doesn't get decremented. In general, spurious
> > interrupts shouldn't happen, which is why it has managed to lurk here
> > for so long.
> 
> Well, I think the right question here is why scheduler lock is
> incremented at all? I mean if SMP implementations happen to increment it
> inside the interrupt_end(), then it should be safe for ARM HAL to
> increment it just before calling interrupt_end(), isn't it? This way
> spurious interrupt handling code will avoid both scheduler lock
> increment and interrupt_end() call. Makes sense?

The scheduler lock has several duties. As well as disabling thread
suspension and controlling when DSRs are called, it also does duty as
an interrupt nesting counter. We only want DSRs to be called when all
nested interrupts have been unwound and we are about to return from
the first one. The scheduler lock count does this implicitly. But for
this to work properly, the scheduler lock must be incremented in the
VSR before interrupts are re-enabled and the ISR is called.

In the SMP case I decided, at least initially, that nested interrupts
would not be supported. It was hard enough keeping track of interrupts
going off on different CPUs. This allowed me to move the lock
operation into interrupt_end(), and avoided having to write any asm
code to go into the VSR.

SMP is really still in its development phase, there are a number of
things that a little experimental in there. Moving the scheduler
locking to interrupt_end() was one of them. I certainly would not want
to do that for any other configuration.


-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss