interrupt handling on task scheduling

[Joel Sherrill <joel@OARcorp.com>]

Francesco Poletti wrote:
> Hi Joel,
> thanks for the first answer...Sorry to bother you again...
> 
> We discovered that for the arm boards the function
>  _CPU_ISR_Disable(level);
>  _CPU_ISR_Enable(level);
> Doesn't change the previous state of the interrupt instead the 
> _CPU_ISR_Set_level(); When is invoked it enables all the interrupt.
> Is this behaviour correct? Should we read the porting manual for better
> understand it?

The porting manual probably (hopefully) has the best description but the
simple answer is that enable is supposed to take the level back to what
is was based upon the "cookie"

   start with interrupts enabled
   disable(x)
     disable(y)
     enable(y)   -- interrupts still disabled
   enable(x)     -- interrupts enabled

> The strange fact is that in our case when the idle task is scheduled: sometimes
> the _CPU_ISR_Set_level();  is invoked and other times no.
> So when this function is runned everything works ok for us, but on the other
> hand if noone calls this function the interrupt remain disabled...
> 
> Who invoke the _CPU_ISR_Set_level()? Because we were unfortunately able to
> understand that...

a find/grep is probably the best answer to this but I wouldn't expect
it to be executed very many places.  Look for _ISR_Set_level.  That is
the proper name of the portability wrapper.

You may only be seeing interrupts enabled when a new task sets its
initial interrupt level.  That is probably the most common invocation.

> And more, in which part of the code we can see that the idle task is scheduled
> and started?

It only runs when there is nothing else to do.  So it is an implicit
task switch.  Nothing to really trigger on.


> Really thanks in advance.
> 
> Francesco.
> 
> 
> 
> 
>>Francesco Poletti wrote:
>>
>>>Hy all,
>>>We have a porting for the rtems 4.6 working on our simulated arm board.
>>>We are developing message passing support for a multiprocessor context with the
>>>help of dedicated hardware.
>>>We are pointing out some problems in the interrupt handling while the systems is
>>>supending a task...
>>>Basically we notice that while we run the command rtems_task_suspend(RTEMS_SELF)
>>>the OS sometimes performe this sequency of command:
>>>_CPU_ISR_Disable(level);
>>>_CPU_ISR_Flash();
>>>_CPU_ISR_Enable(level)
>>>
>>>_CPU_ISR_Disable(level);
>>>_CPU_ISR_Enable(level)
>>>
>>>_CPU_ISR_Set_level(); //which enforce the system to reable the interrupt on arm
>>>processor
>>>
>>>We need that the OS reable the interrupt because we supsend the thread waiting
>>>for an interrupt and at the same time we have already run
>>>_CPU_ISR_Disable(level); for give to the critical section of our API the
>>>interrupt safeness... Of course if none reables the interrupt handling before
>>>the task suspends then the systems get locked...
>>>
>>>The point is that we were not able to understand from where the
>>>_CPU_ISR_Set_level()is launched...
>>>As far as we noticed it's invoked when the new task is scheduled...is it
> 
> possible?
> 
>>Interrupt disable levelis part of the per-thread context.  So if a
>>thread blocks with interrupts disabled, they are potentially reenabled
>>as part of the switch to another thread.  The IDLE thread should have
>>interrupts enabled almost all the time (except during switching it
>>in and out) so if the application threads all disable interrupts, there
>>will be no interrupt processing until the IDLE thread runs.
>>
>>I think this matches your described behavior and is expected.  If
>>a thread disables interrupts and blocks, then they stay disabled
>>until another thread is switched to.
>>
>>--joel
>>
>>
>>
>>>Thanks in advance, Francesco.
>>>
>>>
>>>
>>>
>>
>>
>>-- 
>>Joel Sherrill, Ph.D.             Director of Research & Development
>>joel at OARcorp.com                 On-Line Applications Research
>>Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>    Support Available             (256) 722-9985
>>
> 
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985