rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
I continued debugging.
It turned out _Thread_Unblock is not called because in _Event_Surrender
(called directly by rtems_event_send) boolean var unblock is false.
to be more exact, in
  if (
    _Event_Is_blocking_on_event( the_thread, wait_class )
      && _Event_Is_satisfied( the_thread, pending_events, &seized_events )
  )
the _Event_Is_blocking_on_event( the_thread, wait_class ) condition fails,
hence the else is entered, unblock is set
to false, _Thread_Unblock not called anymore; and since the call chain was
_Thread_Unblock->_Thread_Clear_state->_Scheduler_Unblock->_Scheduler_priority_Unblock->_Scheduler_Update_heir->
Context Switch to SCrx
there will be more CS for my task on the CPU.
This worked for 5401 ping packets, but for 5402th and so on it's not
working any more.
_Event_Surrender is called every second, but it fails in the same way every
time.

Now .. why would _Event_Is_blocking_on_event fail ?
regards,
Catalin


On Tue, Oct 2, 2018 at 9:55 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 02/10/2018 08:48, Catalin Demergian wrote:
> > Hi,
> > This assert may not be directly related to my issue because I
> > reproduced it a few times (with RTEMS_DEBUG enabled in the build)
> > without seeing the assert being hit. What I discovered is that after a
> > while _Scheduler_priotity_Unblock is not called for my task anymore.
> > And since _Scheduler_priotity_Unblock calls _Scheduler_Update_heir, my
> > task will not be set as the heir and no context switch will be made
> > for it.
> >
> > My question is why would _Scheduler_priority_Unblock not beeing called ?
>
> The _Scheduler_priority_Unblock() is called by _Thread_Unblock() only if
> the thread state changes from not-ready to ready.
>
> > rtems_event_send called from my USB ISR calls _Event_Surrender and
> > that calls _Thread_Unblock
> > Is there a conceptual problem calling rtems_event_send from an ISR ?
>
> Using rtems_event_send() from an ISR is a standard use case.
>
> > I saw there is a rtems_event_system_send function. should I call this
> > one instead ? what is the difference?
>
> It is a different event set, one for applications and one for the system.
>
> --
> 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/20181002/e5cc1636/attachment.html>