I think this patch is wrong. Subsequent changes to the thread queue after I posted this resulted in the test breaking again.
What is the test trying to do? I think sometimes through the loop, the condition the test expects is not occurring and it fails. On Jul 9, 2014 9:32 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: On 2014-07-08 22:52, Joel Sherrill wrote: > The test assumed that the thread would have enough time to block > and become enqueued. In fact, the thread would still be in the > ready state and not blocked on the semaphore. Thus the state > of the Wait sub-structure in the TCB would not be in the expected > state. The simple solution was to continue when the thread was > in the ready state. > --- > testsuites/sptests/spintrcritical20/init.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/testsuites/sptests/spintrcritical20/init.c > b/testsuites/sptests/spintrcritical20/init.c > index cae8fdb..209c9e5 100644 > --- a/testsuites/sptests/spintrcritical20/init.c > +++ b/testsuites/sptests/spintrcritical20/init.c > @@ -20,6 +20,7 @@ > #include <intrcritical.h> > #include <rtems/score/threadqimpl.h> > #include <rtems/rtems/semimpl.h> > +#include <rtems/score/statesimpl.h> > > const char rtems_test_name[] = "SPINTRCRITICAL 20"; > > @@ -108,6 +109,9 @@ static void Init(rtems_task_argument ignored) > ++resets; > } > > + if (ctx->semaphore_task_tcb->current_state == STATES_READY) > + continue; In case the semaphore task is ready at this point, then we have a massive problem since the semaphore task has a higher priority. > + > _Thread_Disable_dispatch(); Should this check move to here? > > rtems_test_assert( > -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel