On 24/10/2018 11:10, Catalin Demergian wrote:
Hi,
I made a debug patch with some changes
in _Scheduler_priority_Ready_queue_enqueue
if(tcb->Object.id == 0x0a010005)
cnt_before = _Chain_Node_count_unprotected(ready_chain);
_Chain_Append_unprotected( ready_chain, node );
if(tcb->Object.id == 0x0a010005) {
cnt_after = _Chain_Node_count_unprotected(ready_chain);
if(cnt_after != cnt_before + 1)
append_errs++;
}
_Priority_bit_map_Add( bit_map, &ready_queue->Priority_map );
I wanted to know if _Chain_Append_unprotected fails when adding my
SCrx task in the ready queue. Since it's a void
function, I used _Chain_Node_count_unprotected to test if the counter
after the insert is the count before + 1.
The task command shows 2 ready tasks, but ready_queue_100_elems=1
(in ready_queue_100_elems I'm saving what
_Chain_Node_count_unprotected returns for ready_queues[100])
Also, append_errs=1, which means that at some point there was an
insert failure.
[/] # task
ID NAME PRI STATE MODES EVENTS WAITID WAITARG
NOTES
------------------------------------------------------------------------------
0a010001 UI1 1 Wevnt P:T:nA NONE 2002b0a4 0x80000000
0a010002 LOGT 99 Wmsg P:T:nA NONE 22010001 0x80000000
0a010003 ntwk 100 Wsysev P:T:nA NONE 2005e43c 0x80000000
0a010004 SCtx 100 Wsysev P:T:nA NONE 2005ff6c 0x80000000
0a010005 SCrx 100 READY P:T:nA 08000000 20060fbc 0x80000000
0a010006 SHLL 100 READY P:T:nA NONE 00000001 0x80000000
[/] #
[/] #
[/] #
[/] # i
Instruction count for the last second is 215993000.
CPU load is 99.99%.
intr_cnt=125916
cond1=0
cond2=1
jiffies=62980862
dbg_ready_UI1=288379
dbg_ready_LOGT=374942
dbg_ready_ntwk=62980798317434
dbg_ready_SCtx=62980515317452
dbg_ready_SCrx=8947511142891
dbg_ready_SHLL=62980853317438
dbg_extract_UI1=67129036
dbg_extract_LOGT=67147087
dbg_extract_ntwk=62980798327798
dbg_extract_SCtx=62980515326397
dbg_extract_SCrx=8947511124432
dbg_extract_SHLL=62980852322225
append_errs=1
ready_queue_100_elems=1
[/] #
My theory is that because the SCrx task is in a funny state where
current_state=READY, but it's not in the ready queue because
of the insert failure, it will never be scheduled again because no
matter how many USB interrupts may arrive, unblock will be set to FALSE
in _Event_Surrender because the state is READY
so _Event_Is_blocking_on_event returns FALSE.
Could this theory be valid ?
Yes, this sounds valid. It fits also into the assertion failure reported
in one of your previous e-mails.
Can you set a break point to the
append_errs++;
line? A stack trace would be helpful. I would also have a look at the
chain data structures.
I would add an extra debug state to the thread control block to ensure
that you don't have a double insert/extract into the ready queue.
--
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
