<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div>I made a debug patch with some changes in _Scheduler_priority_Ready_queue_enqueue</div><div><div><br></div><div> if(tcb->Object.id == 0x0a010005)</div><div><span style="white-space:pre"> </span> cnt_before = _Chain_Node_count_unprotected(ready_chain);</div><div> _Chain_Append_unprotected( ready_chain, node );</div><div> if(tcb->Object.id == 0x0a010005) {</div><div><span style="white-space:pre"> </span> cnt_after = _Chain_Node_count_unprotected(ready_chain);</div><div><span style="white-space:pre"> </span> if(cnt_after != cnt_before + 1)</div><div><span style="white-space:pre"> </span> append_errs++;</div><div> }</div><div> _Priority_bit_map_Add( bit_map, &ready_queue->Priority_map );</div><div><br></div></div><div>I wanted to know if _Chain_Append_unprotected fails when adding my SCrx task in the ready queue. Since it's a void</div><div>function, I used _Chain_Node_count_unprotected to test if the counter after the insert is the count before + 1.</div><div><br></div><div>The task command shows 2 ready tasks, but ready_queue_100_elems=1</div><div>(in ready_queue_100_elems I'm saving what _Chain_Node_count_unprotected returns for ready_queues[100])</div><div>Also, append_errs=1, which means that at some point there was an insert failure.</div><div><br></div><div><div>[/] # task</div><div> ID NAME PRI STATE MODES EVENTS WAITID WAITARG NOTES</div><div>------------------------------------------------------------------------------</div><div>0a010001 UI1 1 Wevnt P:T:nA NONE 2002b0a4 0x80000000</div><div>0a010002 LOGT 99 Wmsg P:T:nA NONE 22010001 0x80000000</div><div>0a010003 ntwk 100 Wsysev P:T:nA NONE 2005e43c 0x80000000</div><div>0a010004 SCtx 100 Wsysev P:T:nA NONE 2005ff6c 0x80000000</div><div>0a010005 SCrx 100 READY P:T:nA 08000000 20060fbc 0x80000000</div><div>0a010006 SHLL 100 READY P:T:nA NONE 00000001 0x80000000</div><div>[/] #</div><div>[/] #</div><div>[/] #</div><div>[/] # i</div><div>Instruction count for the last second is 215993000.</div><div>CPU load is 99.99%.</div><div>intr_cnt=125916</div><div>cond1=0</div><div>cond2=1</div><div>jiffies=62980862</div><div>dbg_ready_UI1=288379</div><div>dbg_ready_LOGT=374942</div><div>dbg_ready_ntwk=62980798317434</div><div>dbg_ready_SCtx=62980515317452</div><div>dbg_ready_SCrx=8947511142891</div><div>dbg_ready_SHLL=62980853317438</div><div>dbg_extract_UI1=67129036</div><div>dbg_extract_LOGT=67147087</div><div>dbg_extract_ntwk=62980798327798</div><div>dbg_extract_SCtx=62980515326397</div><div>dbg_extract_SCrx=8947511124432</div><div>dbg_extract_SHLL=62980852322225</div><div>append_errs=1</div><div>ready_queue_100_elems=1</div><div>[/] #</div></div><div><br></div><div>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</div><div>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</div><div>in _Event_Surrender because the state is READY so _Event_Is_blocking_on_event returns FALSE.</div><div><br></div><div>Could this theory be valid ?</div><div><br></div><div>regards</div><div>Catalin</div><div><br></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 23, 2018 at 1:47 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 23/10/2018 10:44, Catalin Demergian wrote:<br>
> Hi,<br>
> I'm logging what rtems_clock_get_ticks_since_boot returns to know when <br>
> I call _Scheduler_priority_Ready_queue_enqueue<br>
> and _Scheduler_priority_Ready_queue_extract, but I'm getting the same <br>
> number, I can't tell the order. My question is,<br>
> do you know if there is something I can call that gives me microsecond <br>
> precision ?<br>
<br>
You can try rtems_clock_get_uptime_nanoseconds().<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>