rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
I'm back investigating this issue.

I started to look in the ready queues implementation. I added a debug patch
tracing my tasks having priority=100.
The way I see it, a task can enter a ready queue only
with _Scheduler_priority_Ready_queue_enqueue/_Scheduler_priority_Ready_queue_enqueue_first
and can be removed only by _Scheduler_priority_Ready_queue_extract.
I logged what rtems_clock_get_ticks_since_boot returns for every task and
what I found was that for SCrx task this value is way behind the value for
other tasks, meaning after a point is not added in the ready queue anymore.
I tried with debugger too, following the next pointers to see what's in the
ready_queue[100] and my task is not there, even if I see the state is ready
when doing task command in shell.
any idea what might be causing this?

regards,
Catalin


On Fri, Oct 12, 2018 at 11:46 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 12/10/2018 10:40, Catalin Demergian wrote:
> > Hi,
> > I still think it would be worth to try the latest RTEMS master just to
> > make sure we don't search a bug which is already fixed. Also RTEMS 5 has
> > more assertions in the debug configuration.
> > -> is RTEMS 5 stable branch or development ?
>
> It is the development branch of RTEMS. Most of the time it is stable.
>
> > -> what is the link for RTEMS master (where to do a git clone from)  ?
>
> git://git.rtems.org/rtems.git
>
> >
> > I have a theory of what may be going on, please let me know if you
> > think it's valid.
> > 1. let's say Wait.flags = THREAD_WAIT_CLASS_EVENT
> > | THREAD_WAIT_STATE_INTEND_TO_BLOCK
> >     and state = STATES_WAITING_FOR_EVENT because they are set this way
> > in _Event_Seize
> > 2. USB ISR arrives, so we go in _Event_Surrender where
> >     success = _Thread_Wait_flags_try_change_critical(
> >       the_thread,
> >       wait_class | THREAD_WAIT_STATE_INTEND_TO_BLOCK,
> >       ready_again
> >     );
> >     will return TRUE, because the expected flags was intend to block,
> > so Wait.flags will become THREAD_WAIT_CLASS_EVENT
> > | THREAD_WAIT_STATE_READY_AGAIN
> > 3. _Event_Seize continues execution with
> >       success = _Thread_Wait_flags_try_change(
> >         executing,
> >         intend_to_block,
> >         wait_class | THREAD_WAIT_STATE_BLOCKED
> >       );
> >       and success will be FALSE because Wait.flags is not
> > THREAD_WAIT_STATE_INTEND_TO_BLOCK anymore, so _Thread_Unblock will get
> > called
> >       and eventually _States_Clear will put state = STATES_READY.
>
> Yes, and the _Thread_Unblock() will result in a call to
> _Scheduler_Unblock(). This adds the thread to the set of ready threads
> and it will execute as soon it is the highest priority ready thread.
>
> > 4.  _Thread_Dispatch_enable will be called in _Event_Seize, but
> > another task is selected to run (I have 4 tasks with the same
> > priority, my task doesn't have a smaller
> >      priority, it's not necessarily made the heir task)
> > 5.  Another USB ISR arrives; this time we enter _Event_Surrender with
> >      state = STATES_READY and Wait.flags = THREAD_WAIT_CLASS_EVENT
> > | THREAD_WAIT_STATE_READY_AGAIN,
> >      so we go on the else branch, setting unblock = FALSE, not
> > calling _Thread_Unblock from _Event_Surrender.
> > 6.  basically no matter how many USB ISRs will arrive, the same
> > scenario from step 5 repeats ... no one will call _Thread_Unblock for
> > SCrx again !
> >      Also, when entering task command in the shell it shows the task
> > as ready (because it is) and the USB event set.
>
> Once the thread is in the set of ready threads managed by the scheduler
> another call to _Thread_Unblock() is unnecessary.
>
> --
> 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20181022/3abc1417/attachment-0002.html>