This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Cmem heap allocation/deallocation issue on DM365 based IPNC

Hello,

I have a strange issue with CMEM_alloc from the heap. I am allocating buffer 1 and then buffer2. Both of size 100 bytes. If I free first buffer 1 and then buffer 2, I get CMEMK Error: FREE: Failed to convert virtual 0x40001000 to physical. 0x40001000 is the address of buffer 2.

But if I free first buffer 2 and then buffer 1, everything runs fine.

I have attached the source code of my program and also a log of the error messages collected with CMEM.debug = true, for both the passing and failing cases. The 2 logs are almost identical except for the last line.

My cmem is loaded as follow:

mod cmemk.ko phys_start=0x83800000 phys_end=0x88000000 allowOverlap=1 phys_start_1=0x00001000 phys_end_1=0x00008000 pools_1=1x28672

 

 Victor

 

cmem_issue.zip
  • What version of Linux Utils are you using?

    There have been a few bug fixes lately (especially WRT cache and heap-based allocations), you might try updating and seeing if this is reproducible with the latest:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/index.html

    Chris

  • Victor,
    Is this some custom version of CMEM?
    I ask because I see user-level trace that can't come from any released Linux Utils trees - the cacheInv operations in the middle of CMEM_free().  I recall that we sent a user-level workaround to some customer, for a bug fix with the cache inv inside CMEM_free(), and after confirmation that it fixed things we put the cache inv operation in the kernel module for the true fix, included in Linux Utils 2.24.04.  The bug is SDOCM00066886 - 'CMEM needs to cache-invalidate heap block during "free" operation for cached allocations'
     
    Another odd thing is that the code shows CMEM_CACHED allocs, but the debug info shows CMEM_NONCACHED from the CMEM_alloc() trace.  No idea how this might be happening.
     
    Then there is the 'size' printed with the "CMEM_IOCFREEHEAP succeeded" message - it should be the size being freed, not the size of the heap (0x04800000 in this case).
     
    I worry that there is some sort of "custom" CMEM_free() function that might have a problem, so I'd like to see it.  Do you have access to it?
     
    Regards,
     
    - Rob