rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
First of all, I verified if I have this fix in my code base and I do have
it.

"Are the flags == 0x101? In this case the thread is in the middle of
_Event_Seize()"

Yes. Even if in my test the ping packets arrive once at every second
and there is plenty of time, sometimes it

happens that rtems_event_send() is called from the USB ISR when we are
in _Event_Seize (called from rtems_event_receive)

It's rare, but it happens. (it could happen quicker if I run ping flood (-f
option))

"The unblock is done in _Event_Seize() in this case"

Ok, now I understand why THREAD_WAIT_STATE_INTEND_TO_BLOCK exists ...
so that if an ISR arrives before _Thread_Wait_flags_try_change

and changes the wait flags from INTEND_TO_BLOCK to READY_AGAIN, the
function will return false and _Thread_Unblock will get called, right
?

Problem is, I don't think it is called; otherwise I would see the
thread making progress. Maybe there is a synchronization issue with
the wait flags that

I don't understand.


regards,
Catalin


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

>
>
> On 04/10/2018 15:33, Catalin Demergian wrote:
> > I eliminated the theory of memory corruption. I debugged and found we
> > set Wait.flags = 0x104 with a function call.
> > The USB interrupt can arrive at any time, so Wait.flags can be either
> > INTEND_TO_BLOCK, BLOCKED or READY_AGAIN.
> >
> > Following the logic in _Event_Surrender:
> > If it arrives when Wait.flags = INTEND_TO_BLOCK
>
> Are the flags == 0x101? In this case the thread is in the middle of
> _Event_Seize()
>
> > then _Thread_Wait_flags_try_change_critical will return TRUE,
> > Wait.flags will be set to READY_AGAIN,
> > unblock = FALSE so _Thread_Unblock will not be called.
>
> The unblock is done in _Event_Seize() in this case:
>
>    success = _Thread_Wait_flags_try_change_acquire(
>      executing,
>      intend_to_block,
>      wait_class | THREAD_WAIT_STATE_BLOCKED
>    );
>
> The success == false in this case.
>
> > Then all the other USB interrupts will catch Wait.flags = READY_AGAIN
> > and in this case_Event_Surrender doesn't do anything because unblock =
> > FALSE
> >
> > .. so the task never runs again, but state remains marked as READY.
> > is this a bug ? or I'm not understanding correctly?
>
> There could be a synchronization issue with the wait flag or the
> interrupt disable/enable sequence.
>
> There was a severe bug on the ARMv7-M in this area, but it is fixed in
> the 4.11.2 release:
>
>
> https://git.rtems.org/rtems/commit/?h=4.11&id=7e91901303219f10cf865906931c07c31d2e37f4
>
> --
> 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/20181005/c75082eb/attachment-0002.html>