This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Re: Problems with "Scheduler lock not zero"
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Juergen Lambrecht <Jurgen dot Lambrecht at scarlet dot be>
- Cc: ecos-discuss at ecos dot sourceware dot org, Andrew Lunn <andrew at lunn dot ch>
- Date: Tue, 24 Jul 2007 13:21:40 +0200
- Subject: Re: [ECOS] Re: Problems with "Scheduler lock not zero"
- References: <46A3DBE1.6080104@telenet.be>
On Mon, Jul 23, 2007 at 12:36:17AM +0200, J?rgen Lambrecht wrote:
> Hello Andrew,
>
> You say below that there has been problems on the ARM platform not
> correctly dealing with spurious interrupts.
>
> Is this a problem of the ARM processor or a problem in eCos? If it is a
> problem in eCos, I would like to try to solve it. I'm on holidays, so I
> have time to do some coding for fun, not for work :-).
Spurious interrupts is generally a hardware problem. It means
something generated an interrupt, but the advanced interrupt
controller does not know what caused the interrupt. It is also very
hard to test code which deals with this, unless you have some broken
hardware.
> You also say below that "Scheduler lock not zero" can be caused by a thread
> exiting with the scheduler locked. In a release SW, so without assertions,
> does this crash the SW or is this solved by eCos?
The scheduler is left locked, so the system just stops running
threads. When i found this problem, the relevant bit of code was
looked at and it is not easy to do anything about it. Also, doing
anything about this just hides bugs in the application code. The
assert seems to be the correct thing to do.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss