rtems_semaphore_obtain problems identified

[Kate Feng]

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.

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