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 ?
regards
Catalin
On Tue, Oct 23, 2018 at 1:47 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 23/10/2018 10:44, Catalin Demergian wrote:
> > Hi,
> > I'm logging what rtems_clock_get_ticks_since_boot returns to know when
> > I call _Scheduler_priority_Ready_queue_enqueue
> > and _Scheduler_priority_Ready_queue_extract, but I'm getting the same
> > number, I can't tell the order. My question is,
> > do you know if there is something I can call that gives me microsecond
> > precision ?
>
> You can try rtems_clock_get_uptime_nanoseconds().
>
> --
> 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
