rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
I put more debugging effort into this.

I think it's all about the Wait.flags value when the ISR is arriving.
For Wait.flags=BLOCKED or Wait.flags=INTEND_TO_BLOCK things are working
(yes, _Thread_Unblock is called from _Event_Seize properly), but when
Wait.flags=READY
things don't work because the conditions in if block from _Event_Surrender
are not met and
nobody calls _Thread_Unblock; even if more ISRs arrive, Wait.flags remains
READY and the
thread is not put on the CPU anymore.

1. how can Wait.flags be READY before the ISR is arriving ?
2. on the else of the if block I tried to put unblock=true to unblock my
task
  if (
    _Event_Is_blocking_on_event( the_thread, wait_class )
      && _Event_Is_satisfied( the_thread, pending_events, &seized_events )
  ) {
, I did see _Thread_Unblock called, but in _Thread_Clear_state
_Scheduler_Unblock was not called
because the_thread->current_state = 0.
do I have to set something else besides unblock=true to unblock my task ?

regards,
Catalin



On Fri, Oct 5, 2018 at 3:58 PM Catalin Demergian <demergian at gmail.com>
wrote:

> 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/20181009/156984c8/attachment-0002.html>