Memory Barrier (was RE: rtems_semaphore_obtain problems identified)

[Feng, Kate]

Joel Sherrill wrote :

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

It looks like it, but RTEMS4.7.x still needs patches.
This is not even fixed in 4.77.99.2.
The memory barrier definitely should be fixed in RTEMS4.7.x
before jumping to RTEMS4.8.

Suggestions follow, except I hope I do not miss anything
since I came up with this a while ago.

1) In cpukit/score/include/rtems/system.h:

#define RTEMS_COMPILER_MEMORY_BARRIER() asm volatile(::: "memory")

seems to be wrong and misplaced.

The memory barrier is processor dependent.
For example, the memory barrier for PowerPC is "sync".

Thus, for PPC,  it would seem more functional to place
#define RTEMS_COMPILER_MEMORY_BARRIER() asm volatile("sync"::: "memory")

in cpukit/score/cpu/powerpc/system.h
or somewhere in the processor branch.


2) In order for the inline to work, the 
CPU_INLINE_ENABLE_DISPATCH should be defined to be TRUE.

Thus,
in cpukit/score/cpu/powerpc/rtems/score/cpu.h:

-#define CPU_INLINE_ENABLE_DISPATCH       FALSE
+#define CPU_INLINE_ENABLE_DISPATCH       TRUE 




3) Among PPC shared/irq/irq.c and other PPCs, 
_ISR_Disable( _level ), and _ISR_Disable( _level )
should be used instead of _CPU_ISR_Disable(level) and
_CPU_ISR_Enable( _level )

Actually, I think a better one should be rtems_interrupt_disable(level)
and rtems_interrupt_enable(level).

Kate


-----Original Message-----
From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
Sent: Wed 5/2/2007 12:09 PM
To: Kate Feng
Cc: Chris Johns; rtems-users at rtems.org
Subject: Re: rtems_semaphore_obtain problems identified
 
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
>>>>
>>>>         
>>>       
>
>