• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 751 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

L138: rmmod syslink.ko in App loader returns: ERROR: Module syslink is in use

Bastian
Intellectual 430 points

Hello,

we are running dsp-code on an OMAP L138 under linux.
A linux host program is loading and unloading the dsp-code and the dsp is working
good, so far.

syslink version is: 2_21_02_10

The host program is loading the dsp-code like the "App loader" described
on the SysLink Boot Modes WIKI, expect the ProcMgr_map and ProcMgr_unmap steps.

Before loading the dsp-code, the host program loads the linux syslink kernel module.
This is done with the system function: system("insmod syslink.ko");
After that lsmod on linux gives: syslink used by 0
Then the dsp-code is loaded and working fine.
lsmod on linux gives: syslink used by 17 !

Then the host-code unloads the dsp-code,
lsmod on linux gives: syslink used by 2

And system("rmmod syslink"); gives ERROR: Module syslink is in use

After killing the host-program, lsmod on linux gives: syslink used by 0.
Then it is possible to remove the syslink kernel driver via bash.

So, it seems: Unloading the dsp-code in the ARM host-program is leaving something
in the syslink.ko driver.

Where is the "lsmod used by" (proc fs) information changed in the syslink driver?

Is this problem related to the "missing" ProcMgr_map and ProcMgr_unmap?
I don´t know what to map in at the moment.

Thank you for your effort,

regards,

Bastian.

  • 0
    TI__Guru** 116100 points
    Hi,
    What is your Linux kernel version ?
    Can you please try the syslink default example code for the same test ?
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 430 points

    Hello Titusrathinaraj Stalin,

    the kernel Version is 3.6.7.

    My code is based on the ex06_listmp example.
    This example worked fine after adjusting shared/config.bld to the
    needs of my system.
    The steps slaveloader startup, run example and slaveloader shutdown are
    working. After that i am able to unload the syslink kernel driver via
    bash. But the slaveloader app has finished in that situation.

    So i modified the slaveloader to keep it running at the end and I run into the same issue!

    Using following patch makes the syslink driver "used by 2" and busy until the slaveloader returned from main.


    diff --git a/packages/ti/syslink/samples/hlos/slaveLoader/usr/Linux/SlaveLoaderOS.c b/packages/ti/syslink/samples/hlos/slaveLoader/usr/Linux/SlaveLoaderOS.c
    index 03a7e47..5aa13a0 100755
    --- a/packages/ti/syslink/samples/hlos/slaveLoader/usr/Linux/SlaveLoaderOS.c
    +++ b/packages/ti/syslink/samples/hlos/slaveLoader/usr/Linux/SlaveLoaderOS.c
    @@ -87,7 +87,10 @@ main (int argc, char ** argv)
         Int     remoteArgc   = 0;
         String  *remoteArgv  = NULL;
         Int     i;
    +    Int iTemp = 0;
    +    char buf[256];
     
    +    printf("modified SlaveLoader!\n");
         SysLink_setup ();
     
         /* Execute common startup functionality for all sample applications */
    @@ -228,6 +231,7 @@ main (int argc, char ** argv)
             }
     
             status = SlaveLoader_shutdown(procId, argv [1], mapFile);
    +    iTemp = 1;
         }
     
         /* Execute common shutdown functionality for all sample applications */
    @@ -235,6 +239,15 @@ main (int argc, char ** argv)
     
         SysLink_destroy();
     
    +    if(1==iTemp)
    +      {
    +    printf("SlaveLoaderOS modified, after Syslink_destroy!!!\n");
    +    printf("Type key to return\n");
    +    if(fgets(buf,256,stdin)!=0){
    +      ;
    +    }
    +      }
    +
         return 0;
     }
     
    Please help to find out what is still to cleanup.

    Regards, Bastian.

  • 0 in reply to Bastian
    Intellectual 430 points
    Hello again,

    I tried to look for this issue in syslink - code:

    In the functions Ipc_setup and Ipc_destroy the
    ringIOInitFlag is used for RingIO_setup and RingIOShm_setup.
    And this flag is set to FALSE in Ipc_destroy and prevent the
    RingIOShm_destroy() call.

    This hack reduced the "insmod used by" to 1:

    diff --git a/packages/ti/syslink/ipc/hlos/usr/Ipc.c b/packages/ti/syslink/ipc/hlos/usr/Ipc
    index 7e7a90f..8ef20db 100755
    --- a/packages/ti/syslink/ipc/hlos/usr/Ipc.c
    +++ b/packages/ti/syslink/ipc/hlos/usr/Ipc.c
    @@ -855,7 +855,7 @@ Ipc_destroy (void)
    }
    else {
    #endif /* if !defined(SYSLINK_BUILD_OPTIMIZE) */
    - Ipc_state.ringIOInitFlag = FALSE;
    + //Ipc_state.ringIOInitFlag = FALSE;
    #if !defined(SYSLINK_BUILD_OPTIMIZE)
    }
    #endif /* if !defined(SYSLINK_BUILD_OPTIMIZE) */



    And in the function MessageQDrv_open() i think there is one "MessageQDrv_refCount++" too much.
    This prevents to close(MessageQDrv_handle);

    With the following hack the driver can removed and reloaded by the App Loader, or the Slaveloader.

    diff --git a/packages/ti/syslink/ipc/hlos/usr/Linux/MessageQDrv.c b/packages/ti/syslink/ip
    index ecb76c1..802d60c 100755
    --- a/packages/ti/syslink/ipc/hlos/usr/Linux/MessageQDrv.c
    +++ b/packages/ti/syslink/ipc/hlos/usr/Linux/MessageQDrv.c
    @@ -144,9 +144,9 @@ Int MessageQDrv_open(Void)
    }
    }

    - if (status == MessageQ_S_SUCCESS) {
    - MessageQDrv_refCount++;
    - }
    + //if (status == MessageQ_S_SUCCESS) {
    + // MessageQDrv_refCount++;
    + //}

    /* failure case */
    if (status < 0) {



    But this are hacks and it is working for my system here!
    Perhaps you would like to tune the SysLink code for the next release?!

    Regards,

    Bastian.