<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div>I'm back investigating this issue.</div><div><br></div><div>I started to look in the ready queues implementation. I added a debug patch tracing my tasks having priority=100.</div><div>The way I see it, a task can enter a ready queue only with _Scheduler_priority_Ready_queue_enqueue/_Scheduler_priority_Ready_queue_enqueue_first</div><div>and can be removed only by _Scheduler_priority_Ready_queue_extract.</div><div>I logged what rtems_clock_get_ticks_since_boot returns for every task and what I found was that for SCrx task this value is way behind the value for</div><div>other tasks, meaning after a point is not added in the ready queue anymore.</div><div>I tried with debugger too, following the next pointers to see what's in the ready_queue[100] and my task is not there, even if I see the state is ready</div><div>when doing task command in shell.</div><div>any idea what might be causing this?</div><div><br></div><div>regards,</div><div>Catalin</div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018 at 11:46 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/10/2018 10:40, Catalin Demergian wrote:<br>
> Hi,<br>
> I still think it would be worth to try the latest RTEMS master just to<br>
> make sure we don't search a bug which is already fixed. Also RTEMS 5 has<br>
> more assertions in the debug configuration.<br>
> -> is RTEMS 5 stable branch or development ?<br>
<br>
It is the development branch of RTEMS. Most of the time it is stable.<br>
<br>
> -> what is the link for RTEMS master (where to do a git clone from) ?<br>
<br>
git://<a href="http://git.rtems.org/rtems.git" rel="noreferrer" target="_blank">git.rtems.org/rtems.git</a><br>
<br>
><br>
> I have a theory of what may be going on, please let me know if you <br>
> think it's valid.<br>
> 1. let's say Wait.flags = THREAD_WAIT_CLASS_EVENT <br>
> | THREAD_WAIT_STATE_INTEND_TO_BLOCK<br>
> and state = STATES_WAITING_FOR_EVENT because they are set this way <br>
> in _Event_Seize<br>
> 2. USB ISR arrives, so we go in _Event_Surrender where<br>
> success = _Thread_Wait_flags_try_change_critical(<br>
> the_thread,<br>
> wait_class | THREAD_WAIT_STATE_INTEND_TO_BLOCK,<br>
> ready_again<br>
> );<br>
> will return TRUE, because the expected flags was intend to block, <br>
> so Wait.flags will become THREAD_WAIT_CLASS_EVENT <br>
> | THREAD_WAIT_STATE_READY_AGAIN<br>
> 3. _Event_Seize continues execution with<br>
> success = _Thread_Wait_flags_try_change(<br>
> executing,<br>
> intend_to_block,<br>
> wait_class | THREAD_WAIT_STATE_BLOCKED<br>
> );<br>
> and success will be FALSE because Wait.flags is not <br>
> THREAD_WAIT_STATE_INTEND_TO_BLOCK anymore, so _Thread_Unblock will get <br>
> called<br>
> and eventually _States_Clear will put state = STATES_READY.<br>
<br>
Yes, and the _Thread_Unblock() will result in a call to <br>
_Scheduler_Unblock(). This adds the thread to the set of ready threads <br>
and it will execute as soon it is the highest priority ready thread.<br>
<br>
> 4. _Thread_Dispatch_enable will be called in _Event_Seize, but <br>
> another task is selected to run (I have 4 tasks with the same <br>
> priority, my task doesn't have a smaller<br>
> priority, it's not necessarily made the heir task)<br>
> 5. Another USB ISR arrives; this time we enter _Event_Surrender with<br>
> state = STATES_READY and Wait.flags = THREAD_WAIT_CLASS_EVENT <br>
> | THREAD_WAIT_STATE_READY_AGAIN,<br>
> so we go on the else branch, setting unblock = FALSE, not <br>
> calling _Thread_Unblock from _Event_Surrender.<br>
> 6. basically no matter how many USB ISRs will arrive, the same <br>
> scenario from step 5 repeats ... no one will call _Thread_Unblock for <br>
> SCrx again !<br>
> Also, when entering task command in the shell it shows the task <br>
> as ready (because it is) and the USB event set.<br>
<br>
Once the thread is in the set of ready threads managed by the scheduler <br>
another call to _Thread_Unblock() is unnecessary.<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div>