• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 930 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Desktop Linux SDK cmem userAddr bad values

Chris Johnson1
Expert 1715 points

Hello,

I have a Linux application that uses the Desktop Linux SDK to work with a DSPC-8681 card. I am using the cmem module to allocate some shared memory. I haven't had any issues with the application on the few servers I've tested with so far, but I recently moved the application to a server that is showing problems.

After I call cmem_drv_alloc(), I try to read back the first 4 bytes from cmem_host_buf_desc_t.userAddr. On the other servers I have used, this always comes up as 0 initially. I can then set it to a different value and read it back as the new value. On the server in question that is exhibiting problems when I read back this value it comes up as 0x FFFF FFFF. If I set it to a different value and read it back right away, I can usually see it as the new value, but a second read or a read after some other line of code has the value being read as 0x FFFF FFFF again.

The server in question is running CentOS 7.1.1503 and Linux kernel 3.15.6.  

I have been using Desktop Linux 01.00.00.07, but after seeing this error, I tested on the problem server with version 01.00.03.00 and still see the same issue.

Has anyone else encountered a similar issue?

Is there anything I need to configure to get this to work? 

Is there anything else I can look at to get more information on what could be causing the problem?

Regards,
Chris Johnson

  • 0
    TI__Guru* 81335 points
    Hi Chris,
    We recommend customer to use Ubuntu 12 or 14.04 for Desktop Linux SDK however I will check with internal team on this issue and get back to you.
    Thank you
  • 0 in reply to Raja
    Expert 1715 points
    Thanks for looking into this Raja.

    I have ran this successfully on another server that's running CentOS 6.6, so I was hoping the Linux OS wouldn't be the problem. I know CentOS 7 added a lot of new things though so maybe it's related to that specific version of CentOS.

    Regards,
    Chris
  • 0 in reply to Chris Johnson1
    TI__Mastermind 28085 points
    Hi,

    Both CentOS 6.6 and 7 are 32-bit or 64-bit? DSP reset command is not properly works on Ubuntu 14.04 64-bit OS, but the same command works properly on 32-bit OS. Please refer below thread for more information.
    e2e.ti.com/.../1483384

    Thanks,
  • 0 in reply to Ganapathi Dhandapani95
    Expert 1715 points
    Ganapathi,

    Every OS that I have used is 64-bit. I'm not seeing problems with the dnldmgr_reset_dsp() function calls only with the host-mapped memory setup on the server with the problem. I did test a server with 64-bit Ubuntu 14.04 and saw the same reset function issue as mentioned in the thread you linked.

    Here is a summary of the Linux environments I have used to test. All of these are 64-bit:
    Ubuntu 12.04 - kernel 3.2.0-49 - PASS
    Ubuntu 14.04 - kernel 3.13.0-63 - FAIL - reset issue as described in the thread you linked
    CentOS 6.6 - kernel 2.6.32 - PASS
    CentOS 7.1 - kernel 3.15.6 - FAIL - shared host-mapped memory issue as described above

    Regards,
    Chris
  • 0 in reply to Chris Johnson1
    TI__Mastermind 28085 points
    Hi,

    Thanks for your test results. It is known issues for latest 64-bit Linux.

    TI has tested Desktop linux package on Ubuntu Linux 12.04 LTS 32-bit and 64-bit OS only. Better to use this version for your testing.

    Thanks,
  • 0 in reply to Ganapathi Dhandapani95
    Expert 1715 points

    Ganapathi,

    Thanks for the info about the latest 64-bit Linux. Is there a maintained list of current known issues for the Desktop Linux SDK somewhere? The release notes have no known issues listed.

    Regards,
    Chris

  • 0 in reply to Chris Johnson1
    TI__Guru* 81335 points
    Hi Chris,
    I have requested development team to look into this issue for any other suggestion. Thank you for your patience.
  • 0 in reply to Raja
    Genius 3420 points

    Raja-

    > I have requested development team to look into this issue for any other suggestion.

    We understand that TI SDK is not intended to be a product and may only support limited Linux testing.  However, we provide CMEM functionality in our DirectCore software as a product, and we have annual software agreements with our customers who are using 1000s of TI chips, and we need to support various Linux distributions as required by our customers.

    Can you e-mail us privately with internal information on the issue so we can fix it and move forward?   Thanks Raja.

    -Jeff
    Signalogic