rtems_semaphore_obtain

[Jiri Gaisler]

The investigation we made showed that a too fast interrupt rate
can cause a stack overflow and crash the system. Ideally, the
code should be changed such that the current interrupt stack
frame is fully unwound before switching treads and re-enabling
interrupts. This might or might not be difficult to implement,
and might have some undesired side-effects.

Joel, what is your opinion ..?

Jiri.

Joel Sherrill wrote:
> John Pickwick wrote:
>> Hi,
>>
>> on that thread, after Jiri's last message, it is unclear to me if there is 
>> still a problem for LEON2 BSP in the official 4.6.5 release (from RTEMS 
>> site).
>>
>> Please can someone clarify this point, thanx
>>
>>   
> Jiri ships a version of RTEMS with some patches that may or may not be in
> the official tree at any given point in time.  He will have to comment 
> on what
> is in his current patch set.
> 
> But so far, we haven't found anything wrong with RTEMS based upon the 
> test code.
> So far it looks like the code is generating interrupts faster than they 
> can be processed
> and eventually blowing the stack.  There must be enough time between 
> interrupts
> so you do all cleanup from the interrupted task eventually.
> 
> --joel
>> John
>>
>> ----- Original Message ----- 
>> From: "Joel Sherrill" <joel.sherrill at oarcorp.com>
>> To: "Thomas Doerfler (nt)" <Thomas.Doerfler at imd-systems.de>
>> Cc: <rtems-users at rtems.org>
>> Sent: Thursday, March 29, 2007 10:22 PM
>> Subject: Re: rtems_semaphore_obtain
>>
>>
>>   
>>> Thomas Doerfler (nt) wrote:
>>>     
> Hi,
> 
> Some while ago we had a thread on the rtems mailing list which might
> handle your problem. We found out, that gcc takes the liberty to move
> some memory accesses that should occure between the irq disable/enable
> calls to a location before or after the irq disabled section. Try
> looking for a keyword like "memory barrier" on the mailing list archive 
> :-)
> 
> 
>       
>>>> This was my first guess also but it fails with the edge of the 4.6 and
>>>> 4.7 branches
>>>> as well as using events for synchronization so it is most likely not the
>>>> barrier problem
>>>> again.
>>>>
>>>> --joel
>>>>     
> wkr,
> Thomas.
> 
> 
> Johan Zandin schrieb:
> 
>       
>>>>>> Sergei Organov  writes:
>>>>>>
>>>>>>
>>>>>>         
>>>>>>> "Johan Zandin" <johan.zandin at space.se> writes:
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>>       _Context_Switch( &executing->Registers, &heir->Registers );
>>>>>>>>
>>>>>>>>       executing = _Thread_Executing;
>>>>>>>>
>>>>>>>>       _ISR_Disable( level );         -----+
>>>>>>>>                                           |  Region where
>>>>>>>>    }                                      |  an occuring
>>>>>>>>                                           |  interrupt
>>>>>>>>     _Thread_Dispatch_disable_level = 0;   |  causes problems
>>>>>>>>                                           |
>>>>>>>>     _ISR_Enable( level );            -----+
>>>>>>>>
>>>>>>>>             
>>>>>>> But how interrupt can occur when it's disabled in this region?! If
>>>>>>> _ISR_Disable()/_ISR_Enable() don't work on your target, you have hard
>>>>>>> trouble anyway.
>>>>>>>
>>>>>>>           
>>>>>> The HW interrupt occurs but is left pending until ISRs are enabled,
>>>>>> so the ISR does not execute until somewhere within the _ISR_Enable call
>>>>>> (in the first cycle when ISRs are enabled in the CPU again).
>>>>>>
>>>>>> /Johan
>>>>>>
>>>>>> -----------------------------------------------------------
>>>>>> Johan Zandin                      Software Engineer
>>>>>> Saab Space AB                     Phone: +46-31-735 41 47
>>>>>> SE-405 15 Gothenburg, Sweden      Fax:   +46-31-735 40 00
>>>>>> -----------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> rtems-users mailing list
>>>>>> rtems-users at rtems.com
>>>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>>>
>>>>>>         
_______________________________________________
rtems-users mailing list
rtems-users at rtems.com
http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>

>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>
>>>     
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>   

> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users