Re: [ECOS] Re: Problems with "Scheduler lock not zero"

[Jürgen Lambrecht <jurgen dot lambrecht2 at telenet dot be>]

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 :-).

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?


Kind regards,
Juergen

Øyvind Harboe wrote:

   On 11/7/06, Andrew Lunn <andrew@lunn.ch> wrote:

       Hi Folks

       I think it is unlikley this is your problem, but i will mention it
       anyway. I once had an assertion failure in the same place. It was
       caused by a thread exiting with the scheduler locked.


       Another thing to check is do you have an spurious interrupts. There
       has been problems on the ARM platform not correctly dealing with
       this. Since spurious interrupts generally means broken hardware, its
       not the easiest thing to test and debug.
           



   After fixing a bug in our DDR controller(implemented in FPGA), we can
   no longer reproduce the problem..... Crossing fingers.... :-)


   It is hard enough to tell how a system behaves when it works, but to
   explain what possible a *nearly* working DDR controller could result
   in, is pretty much impossible.


   The main symptom of our broken DDR controller was that the whole
   system locked up. We'll run some more overnight testing, but it looks
   like the  "Scheduler lock not zero" assert failure was just another,
   albeit unfatohmable, manifestation of that same problem.





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