Issues with ListMP of IPC/Syslink

Lee,

What versin of IPC are you using?  Are you seeing this on the DSP side?

There is a condition which ListMP returns NULL:

         retElem = SharedRegion_getPtr(elem->prev);

    if (retElem == (ListMP_Elem *)(&(obj->attrs->head))) {
        retElem = NULL;
    }

So if the prev is points to the head of the list it should return NULL.

Note:  ListMP_next() and ListMP_prev() are not atomic.  You need to surround these access with a GateMP.

Judah

Lee Holeva said:

1.  ListMP_prev() does not return NULL when it gets to the beginnig of the list.

I'm not aware of any problems with ListMP_prev() when the beginning of the list is reached?  To help me check this out, is this for ARM-side ListMP_prev()?

Could you show your code snippet that is not working as expected?

Is the ListMP in SharedRegion 0 or some SharedRegion other than 0?

Lee Holeva said:

2.  If I remove nodes from a list using ListMP_remove(), though ListMP_next() will eventually return NULL, ListMP_empty() never returns TRUE.

There is a known bug with ListMP_empty() in SysLink (i.e. ARM-side ListMP_empty(), DSP-side ListMP_empty() should be OK), where the Bool that is eventually returned is not initialized nor set to the correct value.  Since it's uninitialized, the return value is arbitrary, but will probably always be the same if called repeatedly from within one function.  I don't know if the bug number is helpful to you, but it is SDOCM00083749 in our internal bug database.

If this problem is *not* with the ARM-side ListMP_empty() then please let us know.

Thankyou very much for reporting these issues, and for being patient while SysLink 2.x undergoes its growing pains.

I don't have a forecast of a release for a fix for the ListMP_empty() problem, so I'm glad there is a work-around for you.

Regards,

- Rob

Robert Tivy said:

I'm not aware of any problems with ListMP_prev() when the beginning of the list is reached?  To help me check this out, is this for ARM-side ListMP_prev()?

Could you show your code snippet that is not working as expected?

I'm having problems with ListMP on both the DSP and the ARM side.  I think something is uninitialized.  On the DSP side, consider:

while(~ListMP_empty(list)){

elem = NULL;

obj = (object *)ListMP_next(list, elem);

ListMP_remove(list, &(obj->elem));

}

Eventually obj is NULL, but the loop never terminates.

On the ARM -side I have seen occasional failure assertions from ListMP.

Lee

Lee Holeva said:

while(~ListMP_empty(list)){

elem = NULL;

obj = (object *)ListMP_next(list, elem);

ListMP_remove(list, &(obj->elem));

}

Eventually obj is NULL, but the loop never terminates.

Don't you mean to do !ListMP_empty()?  ~ListMP_empty() will always evaluate non-zero, i.e., TRUE (unless, I suppose, it returns 0xffffffff).

Lee Holeva said:

On the ARM -side I have seen occasional failure assertions from ListMP.

Have you already posted these assertions to the forum?

Regards,

- Rob

Robert Tivy said:

Don't you mean to do !ListMP_empty()?  ~ListMP_empty() will always evaluate non-zero, i.e., TRUE (unless, I suppose, it returns 0xffffffff).

I over-looked that.  I'll try changing the code.

Robert Tivy said:

Have you already posted these assertions to the forum?

No, I rebooted the EVM and they went away.  I'll wait to see whether they reappear.

One quest ion, the documentation distinguishes between the "atomic" ListMP_getHead versus the "non-atomic" ListMP_next.  What is meant here? Is getHead removing nodes from the list or simply providing a copy of the node?

Lee

Ok, the problem with ListMP_empty() was mine, using ! instead of ~ fixed that. 

Here is an assertion that I am seeing:

Assertion at Line no: 911 in /home/lholeva/ti-ezsdk_dm816x-evm_5_01_01_80/syslink_2_00_02_80/packages/ti/syslink/ipc/hlos/usr/ListMP.c: (handle != NULL) : failed

If I run my app immediately after rebooting the EVM I do not get this, but If I run the app a second time then I do.  One possible issue may be with ListMP_delete().  What exactly gets deleted?  Will it free all allocations made by memory_alloc(), or do I need to do that?

I take that back about only getting the assertion the second time I run the code.  I got it the first time, but at a different line, 1316 instead of 911.  I have attempted to run TRACE, but I cannot run TRACECLASS=3 with syslink 2.00.02.80 as the EVM never finishes booting if I do this.

I've upgraded Syslink to version 2.00.03.82 and I still get the random occurance of the failure assertions from ListMP.

Lee

Lee Holeva said:

Assertion at Line no: 911 in /home/lholeva/ti-ezsdk_dm816x-evm_5_01_01_80/syslink_2_00_02_80/packages/ti/syslink/ipc/hlos/usr/ListMP.c: (handle != NULL) : failed

That assertion is from ListMP_getHead(), and it happens right at the beginning of the function (at user level, not kernel).  The only way it will assert is if the handle passed in to ListMP_getHead() is actually NULL.

Lee Holeva said:

I take that back about only getting the assertion the second time I run the code.  I got it the first time, but at a different line, 1316 instead of 911

The assertion at line 1316 is from ListMP_next(), and as with your ListMP_getHead() assertion, it happens right at the beginning.  Your code must be passing a NULL handle to those functions.

Lee Holeva said:

I have attempted to run TRACE, but I cannot run TRACECLASS=3 with syslink 2.00.02.80 as the EVM never finishes booting if I do this

syslink.ko TRACE probably wouldn't help for these particular assertions, since the assertion happens at user level.  Those functions do eventually go down to kernel level, though, but with a NULL handle the kernel modules would also assert.

Lee Holeva said:

One possible issue may be with ListMP_delete().  What exactly gets deleted?  Will it free all allocations made by memory_alloc(), or do I need to do that?

ListMP_delete() deletes the ListMP object, and name storage if it has a name, but that's it.  It does not attempt to remove all ListMP elements and free those.  Your application must do that.

Regards,

- Rob

Lee Holeva said:

One quest ion, the documentation distinguishes between the "atomic" ListMP_getHead versus the "non-atomic" ListMP_next.  What is meant here? Is getHead removing nodes from the list or simply providing a copy of the node?

Yes, ListMP_getHead() removes the element, and ListMP_next() simply returns a pointer w/o removing the element.

Ipc package CDOCs are your friend here (which are culled from the ListMP.h file in <ipc>/packages/ti/ipc).

Regards,

- Rob