rtems_semaphore_obtain problems identified

[Joel Sherrill]

Kate Feng wrote:
> Joel Sherrill wrote:
>
>   
>> Kate Feng wrote:
>>     
>>> First, sincere thanks to all the heros who traced down thoses problems.
>>> More below.
>>>
>>> Joel Sherrill wrote:
>>>
>>>
>>>       
>>>> Chris Johns wrote:
>>>>
>>>>         
>>>>> Johan Zandin wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> * RTEMS bug 1237 exists in all RTEMS versions and probably
>>>>>>   on most platforms. It is related to interrupts occuring
>>>>>>   during task switches and the symptoms are that stacks
>>>>>>   may grow too large, overwriting other memory areas.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> I have looked over the patch and it only references the sparc cpu. I am
>>>>> confused about the reference to "most platforms" reference. Do you mean just
>>>>> sparc platforms ?
>>>>>
>>>>>
>>>>>           
>>>> This particular scenario was that a near continuous stream of high rate
>>>> interrupts
>>>> could result in barely getting back to the interrupted task and getting
>>>> another interrupt
>>>> and preempting from that task again and again without ever clearing off
>>>> previous
>>>> interrupt stack frames.
>>>>
>>>> This scenario is completely possible on other CPUs but is aggravated by
>>>> the large
>>>> interrupt stack frame on the SPARC.  I suspect that design factors in
>>>> the _ISR_Dispatch
>>>> code that are port specific may avoid this problem on some ports.
>>>>
>>>> I'm not saying it couldn't happen on another architecture just that each
>>>> port has to
>>>> be evaluated on its own merits.
>>>>
>>>>         
>>> I actually observed the rtems_semaphore_obtain problems in the PowerPC
>>> port long time ago since I was using mvme2307 BSP. My application will
>>> work fine if I used other  function to get around.  However, at application
>>> level, I really prefer to use rtems_semaphore_obtain b/c I have to port lots
>>> of vxWorks applications, where rtems_semaphore_obtain were used.
>>> After all, semaphore is very important  in real-time application.
>>>
>>>
>>>       
>> Then you are not seeing this problem.  In investigating this problem, I
>> had to
>> narrow it down to semaphore specific or more general.  So I modified his
>> original test case to  use events and it failed in the same manner.
>>     
>
> Yes, you are right.  Using events solved my problem.
>
>   
>> So if switching synchronization mechanisms fixed your problem, it likely
>> was something else.  Depending on the RTEMS version, you might have
>> been before the memory barrier patch.  That was an ugly bug and was
>> reported to  cause weird problems.
>>     
>
> It does not seem to be fixed in any version for  the PowerPC port.
> It behaved the same for the RTEMS4.7.1.  I will  try to apply the
> memory barrier patch and report the result.
>   

The memory barrier patch was PR 866 and was merged in March 2006.  It is
in all 4.7 versions.  It first appeared in 4.6.6.

--joel

> Thanks,
> Kate
>
>   
>> --joel
>>
>> --joel
>>     
>>> Thanks,
>>> Kate
>>>
>>>
>>>
>>>       
>>>> Some ports run _ISR_Dispatch at the ISR
>>>> mask
>>>> level of the interrupt that generated the preempt so there would be a
>>>> known limit
>>>> on how many ISR Dispatches could stack.
>>>>
>>>> The SPARC runs ISR Dispatch with all interrupts enabled so the previous ISR
>>>> is fair gain to occur again.
>>>>
>>>> --joel
>>>> --joel
>>>>
>>>>         
>>>>> Regards
>>>>> Chris
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>         
>>>       
>
>