Hi, I'm back investigating this issue. I started to look in the ready queues implementation. I added a debug patch tracing my tasks having priority=100. 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 and can be removed only by _Scheduler_priority_Ready_queue_extract. 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 other tasks, meaning after a point is not added in the ready queue anymore. 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 when doing task command in shell. any idea what might be causing this?
regards, Catalin On Fri, Oct 12, 2018 at 11:46 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 12/10/2018 10:40, Catalin Demergian wrote: > > Hi, > > I still think it would be worth to try the latest RTEMS master just to > > make sure we don't search a bug which is already fixed. Also RTEMS 5 has > > more assertions in the debug configuration. > > -> is RTEMS 5 stable branch or development ? > > It is the development branch of RTEMS. Most of the time it is stable. > > > -> what is the link for RTEMS master (where to do a git clone from) ? > > git://git.rtems.org/rtems.git > > > > > I have a theory of what may be going on, please let me know if you > > think it's valid. > > 1. let's say Wait.flags = THREAD_WAIT_CLASS_EVENT > > | THREAD_WAIT_STATE_INTEND_TO_BLOCK > > and state = STATES_WAITING_FOR_EVENT because they are set this way > > in _Event_Seize > > 2. USB ISR arrives, so we go in _Event_Surrender where > > success = _Thread_Wait_flags_try_change_critical( > > the_thread, > > wait_class | THREAD_WAIT_STATE_INTEND_TO_BLOCK, > > ready_again > > ); > > will return TRUE, because the expected flags was intend to block, > > so Wait.flags will become THREAD_WAIT_CLASS_EVENT > > | THREAD_WAIT_STATE_READY_AGAIN > > 3. _Event_Seize continues execution with > > success = _Thread_Wait_flags_try_change( > > executing, > > intend_to_block, > > wait_class | THREAD_WAIT_STATE_BLOCKED > > ); > > and success will be FALSE because Wait.flags is not > > THREAD_WAIT_STATE_INTEND_TO_BLOCK anymore, so _Thread_Unblock will get > > called > > and eventually _States_Clear will put state = STATES_READY. > > Yes, and the _Thread_Unblock() will result in a call to > _Scheduler_Unblock(). This adds the thread to the set of ready threads > and it will execute as soon it is the highest priority ready thread. > > > 4. _Thread_Dispatch_enable will be called in _Event_Seize, but > > another task is selected to run (I have 4 tasks with the same > > priority, my task doesn't have a smaller > > priority, it's not necessarily made the heir task) > > 5. Another USB ISR arrives; this time we enter _Event_Surrender with > > state = STATES_READY and Wait.flags = THREAD_WAIT_CLASS_EVENT > > | THREAD_WAIT_STATE_READY_AGAIN, > > so we go on the else branch, setting unblock = FALSE, not > > calling _Thread_Unblock from _Event_Surrender. > > 6. basically no matter how many USB ISRs will arrive, the same > > scenario from step 5 repeats ... no one will call _Thread_Unblock for > > SCrx again ! > > Also, when entering task command in the shell it shows the task > > as ready (because it is) and the USB event set. > > Once the thread is in the set of ready threads managed by the scheduler > another call to _Thread_Unblock() is unnecessary. > > -- > 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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users