Sergei Organov <[EMAIL PROTECTED]> writes: > Nick Garnett <[EMAIL PROTECTED]> writes: > > "Joe Porthouse" <[EMAIL PROTECTED]> 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
