rtems_semaphore_obtain problems identified

[Kate Feng]

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.

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