rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

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.huber at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20181024/340434f0/attachment.html>