rtems_semaphore_obtain problems identified

[Joel Sherrill]

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.

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.

--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
>>     
>
>