rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

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 ?
-> what is the link for RTEMS master (where to do a git clone from)  ?

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

regards,
Catalin


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

> On 11/10/2018 15:37, Catalin Demergian wrote:
> > Hi,
> > Yes, there is a call to rtems_task_wake_after in the code; but in that
> > case state should have been STATES_DELAYING, right ?
>
> The
>
> state = 0x0 = STATES_READY
> Wait.flags = 0x02 = THREAD_WAIT_STATE_BLOCKED
>
> looks suspicious. It should be
>
> state = 0x0 = STATES_READY
> Wait.flags = 0x04 = THREAD_WAIT_STATE_READY_AGAIN
>
> after a call to _Thread_Timeout(),
>
> > At another run, I got
> > state = 0x0 = STATES_READY
> > Wait.flags = 0x104 = THREAD_WAIT_CLASS_EVENT |
> > THREAD_WAIT_STATE_READY_AGAIN
> > Why would the state be ready in _Event_Seize ? could that value be
> > corrupt ?
> >
> > I tried with the stack checker as well, but I didn't see any out of
> > band values.
>
> Ok, good.
>
> 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 as
> more assertions in the debug configuration.
>
> --
> 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/20181012/e740d52b/attachment-0002.html>