rtems_message_queue_receive / rtems_event_receive issues
demergian at gmail.com
Tue Oct 9 06:48:34 UTC 2018
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
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
_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 ?
On Fri, Oct 5, 2018 at 3:58 PM Catalin Demergian <demergian at gmail.com>
> First of all, I verified if I have this fix in my code base and I do have
> "Are the flags == 0x101? In this case the thread is in the middle of
> 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.
> 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
>> > 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(
>> 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:
>> 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...
More information about the users