Syslink Ringio Creation crash

Jibin Scaria

Other Parts Discussed in Thread: SYSBIOS

Hi,

I am trying to create Ringios using syslink to communicate to dsp. But After few Ringio creation and deletion RingIO creation is crashing. I am working in 8148 with sysbios _6_32_01_38. Please see the log below.

ENTER : initializeSemaphores +483 
Creating OsalSemaphores
103131f:  rioDspToRtpSemHandle OsalSemaphore_create succeeded 
103131f:  rioRtpToDspSemHandle OsalSemaphore_create succeeded 
EXIT  : initializeSemaphores +513 
ENTER : createRingIO +294 
Creating RingIO grg103131f1 (HOST 3)
RingIO instance created successfully grg103131f1 
EXIT  : createRingIO +336 
ENTER : openRingIO +355 
RingIO instance opened successfully: grg103131f1 
Passed to register call back with RingIO grg103131f1
EXIT  : openRingIO +420 
ENTER : createRingIO +294 
Creating RingIO grg103131f2 (HOST 3)

Assertion at Line no: 1686 in /media/disk2/ezsdk814x/component-sources/syslink_2_00_03_82/packages/ti/syslink/utils/hlos/knl/
Linux/../../../../../../ti/syslink/RingIOShm.c: (obj->ctrlSharedAddr != NULL) : failed
Assertion at Line no: 1700 in /media/disk2/ezsdk814x/component-sources/syslink_2_00_03_82/packages/ti/syslink/utils/hlos/knl/
Linux/../../../../../../ti/syslink/RingIOShm.c: (attrSharedAddr != NULL) : failed
Assertion at Line no: 1715 in /media/disk2/ezsdk814x/component-sources/syslink_2_00_03_82/packages/ti/syslink/utils/hlos/knl/
Linux/../../../../../../ti/syslink/RingIOShm.c: (dataSharedAddr != NULL) : failed
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = d5c3c000
[00000000] *pgd=95c03031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in: syslink grg_gpio spi_uart_drv
CPU: 0    Not tainted  (2.6.37+ #8)
PC is at RingIOShm_create+0x59c/0x8ac [syslink]
LR is at SharedRegion_getCacheLineSize+0x148/0x180 [syslink]
pc : [<bf0976f8>]    lr : [<bf059aa0>]    psr: 80000013
sp : d5c35d58  ip : 00000000  fp : d5c35de4
r10: e184f000  r9 : d5c35e64  r8 : 00000000
r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : 00000100
r3 : 00000080  r2 : 00000080  r1 : 00000000  r0 : 00000000
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 95c3c019  DAC: 00000015
Process rtp (pid: 1298, stack limit = 0xd5c342e8)
Stack: (0xd5c35d58 to 0xd5c36000)
5d40:                                                       ffffffff bf0576fc
5d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5d80: d5c35db4 d5c35d90 bf057c1c bf04b6e8 00000000 00000000 0000008c 00000000
5da0: 00000000 00000000 d5c35de4 d5c35db8 bf04d090 e184c000 0000008c d5c35e64
5dc0: d5c35dfc 0000000f 0000000f beea3194 d5c34000 00000000 d5c35e1c d5c35de8
5de0: bf091050 bf097168 bf04cbd8 bf04b6e8 0000000c 00000000 00000000 e184c000
5e00: 0000000f 00000000 c028f355 0000000f d5c35ef4 d5c35e20 bf0a58dc bf090ef8
5e20: c028f355 beea3194 d5c35e44 d81f6c00 d5c35e54 d5c35e40 c01c4ee8 c0060c60
5e40: 00000002 d81f6c00 d5c35e74 d5c35e58 c01cc5d8 c01c4e98 00000002 d5c35e98
5e60: beea31cc e1849000 00000000 00000000 00000000 00000000 00000000 00000a00
5e80: 00000000 00000000 00000100 00000000 00000000 00000000 00000003 beea327c
5ea0: 0000000c 0004ebf0 00000000 000559c8 00060000 00000000 beea31dc 00022d78
5ec0: 00000000 00000000 00000000 00000000 beea327c 00000000 d77deb80 0000000f
5ee0: 0000000f beea3194 d5c35f04 d5c35ef8 c00c9768 bf0a5610 d5c35f74 d5c35f08
5f00: c00c9e78 c00c974c beea06e0 d74f6800 c01c72e0 d82c89c0 4ebc7fc7 1b6b0b01
5f20: 00000142 d74f6800 beea06e0 d5c35f70 00000037 beea06e0 d5c34000 00000000
5f40: 00000001 00000037 00000001 00000000 beea3194 c028f355 0000000f d77deb80
5f60: d5c34000 00000000 d5c35fa4 d5c35f78 c00c9f10 c00c9984 d5c35fa4 00000001
5f80: c00bb050 0000a42c 00000000 0000a380 00000036 c0041f48 00000000 d5c35fa8
5fa0: c0041da0 c00c9ec4 0000a42c 00000000 0000000f c028f355 beea3194 0000000f
5fc0: 0000a42c 00000000 0000a380 00000036 00000000 00000000 400fb000 beea3154
5fe0: 00000000 beea3138 0003d264 402c2aec 20000010 0000000f 00000000 00000000
Backtrace: 
[<bf09715c>] (RingIOShm_create+0x0/0x8ac [syslink]) from [<bf091050>] (RingIO_create+0x164/0x2e8 [syslink])
[<bf090eec>] (RingIO_create+0x0/0x2e8 [syslink]) from [<bf0a58dc>] (RingIODrv_ioctl+0x2d8/0x10c0 [syslink])
 r6:0000000f r5:c028f355 r4:00000000
[<bf0a5604>] (RingIODrv_ioctl+0x0/0x10c0 [syslink]) from [<c00c9768>] (vfs_ioctl+0x28/0x44)
 r8:beea3194 r7:0000000f r6:0000000f r5:d77deb80 r4:00000000
[<c00c9740>] (vfs_ioctl+0x0/0x44) from [<c00c9e78>] (do_vfs_ioctl+0x500/0x540)
[<c00c9978>] (do_vfs_ioctl+0x0/0x540) from [<c00c9f10>] (sys_ioctl+0x58/0x7c)
[<c00c9eb8>] (sys_ioctl+0x0/0x7c) from [<c0041da0>] (ret_fast_syscall+0x0/0x30)
 r8:c0041f48 r7:00000036 r6:0000a380 r5:00000000 r4:0000a42c
Code: e1a01006 e0844000 e1a00008 e58a4018 (e5875000) 
---[ end trace 6583833c0c1f26a1 ]---

Can anybody help me in this?

over 13 years ago

0 Ramsey over 13 years ago

TI__Genius 12025 points

Jibin,

I see that you are using SysLink 2.00.03.82. Would it be possible for you to move to SysLink 2.10.02.17? There were several RingIO bugs fixed on the SysLink 2.10 stream. All releases are available the the following link. You can scan the release notes to see which bugs were fixed.

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

Would you attach your RingIO code for inspection and briefly explain the execution flow for both host and dsp processors. In particular, what is driving the create/delete of the RingIO instances? Are you coordinating this between the processors using notify for example?

Thanks
~ Ramsey

0 Jibin Scaria over 13 years ago in reply to Ramsey

Intellectual 380 points

Hi Ramsey,

I tried using new syslink (2.10.02.17). Looks like RingIO creation problems are solved. But now the syslink is getting to soft lock up after few ringio transactions. please see the linux kernel log below.

dm814x-evm login: SysLink version : 2.10.02.17
SysLink module created on Date:Feb  2 2012 Time:13:57:42
Trace enabled
Trace SetFailureReason enabled
Trace class 3
MemoryOS_map: pa=0x480ca800, va=0xfa0ca800, sz=0x1000
NameServer Module already initialized!
SharedRegion Module already initialized!
GateMP Module already initialized!
MessageQ Module already initialized!
HeapBufMP Module already initialized!
HeapMemMP Module already initialized!
ListMP Module already initialized!
ClientNotifyMgr Module already initialized!
FrameQBufMgr Module already initialized!
FrameQ Module already initialized!
    ProcMgr_getProcInfo: bootMode: [0]
MemoryOS_map: pa=0x48180000, va=0xfa180000, sz=0x3000
MemoryOS_map: pa=0x48140000, va=0xfa140000, sz=0x20000
MemoryOS_map: pa=0x40800000, va=0xe0e00000, sz=0x40000
DM8168DSPPROC_attach: Mapping memory regions
MemoryOS_map: pa=0x48140048, va=0xfa140048, sz=0x4
MemoryOS_map: pa=0x48140044, va=0xfa140044, sz=0x4
MemoryOS_map: pa=0x48140650, va=0xfa140650, sz=0x4
MemoryOS_map: pa=0x48180000, va=0xfa180000, sz=0x2fff
DM8168DSPPROC_attach: slave is now in reset
MemoryOS_map: entry already exists
    mapInfo->src  [0x40800000]
    mapInfo->dst  [0xe0e00000]
    mapInfo->size [0x40000]
MemoryOS_map: pa=0x40e00000, va=0xe0e50000, sz=0x8000
MemoryOS_map: pa=0x40f00000, va=0xe0e60000, sz=0x8000
MemoryOS_map: pa=0x40300000, va=0xe0e80000, sz=0x40000
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x40300000]
    sgList.paddr  [0x40300000]
    sgList.offset [0x0]
    sgList.size [0x40000]

MemoryOS_map: pa=0x40400000, va=0xe0f00000, sz=0x40000
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x40400000]
    sgList.paddr  [0x40400000]
    sgList.offset [0x0]
    sgList.size [0x40000]

    ProcMgr_getProcInfo: bootMode: [0]
OsalDrv_mmap(): setting cache disabled for physical address 40800000

OsalDrv_mmap(): setting cache disabled for physical address 40e00000

OsalDrv_mmap(): setting cache disabled for physical address 40f00000

OsalDrv_mmap(): setting cache disabled for physical address 40300000

OsalDrv_mmap(): setting cache disabled for physical address 40400000

DLOAD: ELF: ELF
DLOAD: ELF file header entry point: 9c311c00
ElfLoaderTrgWrite_copy: translated 0x9c000000 (sva) --> 0x9c000000 (mpa)
MemoryOS_map: pa=0x9c000000, va=0xe1000000, sz=0x220dbc
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c000000]
    sgList.paddr  [0x9c000000]
    sgList.offset [0x0]
    sgList.size [0x220dbc]

ElfLoaderTrgWrite_copy: translated 0x9c220dc0 (sva) --> 0x9c220dc0 (mpa)
MemoryOS_map: pa=0x9c220dc0, va=0xe1300dc0, sz=0x82240
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c220000]
    sgList.paddr  [0x9c220000]
    sgList.offset [0xdc0]
    sgList.size [0x83000]

ElfLoaderTrgWrite_copy: translated 0x9c2a3000 (sva) --> 0x9c2a3000 (mpa)
MemoryOS_map: pa=0x9c2a3000, va=0xe0f80000, sz=0x31e3a
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c2a3000]
    sgList.paddr  [0x9c2a3000]
    sgList.offset [0x0]
    sgList.size [0x31e3a]

ElfLoaderTrgWrite_copy: translated 0x9c2d4e40 (sva) --> 0x9c2d4e40 (mpa)
MemoryOS_map: pa=0x9c2d4e40, va=0xe0fc0e40, sz=0x20000
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c2d4000]
    sgList.paddr  [0x9c2d4000]
    sgList.offset [0xe40]
    sgList.size [0x20e40]

ElfLoaderTrgWrite_copy: translated 0x9c2f4e40 (sva) --> 0x9c2f4e40 (mpa)
MemoryOS_map: pa=0x9c2f4e40, va=0xe0f60e40, sz=0xfc82
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c2f4000]
    sgList.paddr  [0x9c2f4000]
    sgList.offset [0xe40]
    sgList.size [0x10ac2]

ElfLoaderTrgWrite_copy: translated 0x9c304ac8 (sva) --> 0x9c304ac8 (mpa)
MemoryOS_map: pa=0x9c304ac8, va=0xe0ff0ac8, sz=0xd000
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c304000]
    sgList.paddr  [0x9c304000]
    sgList.offset [0xac8]
    sgList.size [0xdac8]

ElfLoaderTrgWrite_copy: translated 0x9c311ac8 (sva) --> 0x9c311ac8 (mpa)
MemoryOS_map: pa=0x9c311ac8, va=0xe0f5eac8, sz=0x138
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c311000]
    sgList.paddr  [0x9c311000]
    sgList.offset [0xac8]
    sgList.size [0xc00]

ElfLoaderTrgWrite_copy: translated 0x9c311c00 (sva) --> 0x9c311c00 (mpa)
MemoryOS_map: pa=0x9c311c00, va=0xe0f76c00, sz=0x2ec
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c311000]
    sgList.paddr  [0x9c311000]
    sgList.offset [0xc00]
    sgList.size [0xeec]

ElfLoaderTrgWrite_copy: translated 0x9c311eec (sva) --> 0x9c311eec (mpa)
MemoryOS_map: pa=0x9c311eec, va=0xe0f7ceec, sz=0x238
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c311000]
    sgList.paddr  [0x9c311000]
    sgList.offset [0xeec]
    sgList.size [0x1124]

ElfLoaderTrgWrite_copy: translated 0x9c312124 (sva) --> 0x9c312124 (mpa)
MemoryOS_map: pa=0x9c312124, va=0xe0fb8124, sz=0x170
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c312000]
    sgList.paddr  [0x9c312000]
    sgList.offset [0x124]
    sgList.size [0x294]

ElfLoaderTrgWrite_copy: translated 0x9c312294 (sva) --> 0x9c312294 (mpa)
MemoryOS_map: pa=0x9c312294, va=0xe0fbe294, sz=0x8
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c312000]
    sgList.paddr  [0x9c312000]
    sgList.offset [0x294]
    sgList.size [0x29c]

ElfLoaderTrgWrite_copy: translated 0x9c31229c (sva) --> 0x9c31229c (mpa)
MemoryOS_map: pa=0x9c31229c, va=0xe0fe629c, sz=0x120
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c312000]
    sgList.paddr  [0x9c312000]
    sgList.offset [0x29c]
    sgList.size [0x3bc]

ElfLoaderTrgWrite_copy: translated 0x9c312400 (sva) --> 0x9c312400 (mpa)
MemoryOS_map: pa=0x9c312400, va=0xe0fec400, sz=0x4c
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c312000]
    sgList.paddr  [0x9c312000]
    sgList.offset [0x400]
    sgList.size [0x44c]

DLOAD: write_arguments_to_args_section: c_args=9c311eec
MemoryOS_map: pa=0x9c311eec, va=0xe1226eec, sz=0x4
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c311000]
    sgList.paddr  [0x9c311000]
    sgList.offset [0xeec]
    sgList.size [0xef0]

    ProcMgr_translateAddr: srcAddr [0x9c311eec] dstAddr [0xe0f7ceec]

MemoryOS_map: pa=0x9c311ef0, va=0xe1230ef0, sz=0x4
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c311000]
    sgList.paddr  [0x9c311000]
    sgList.offset [0xef0]
    sgList.size [0xef4]

    ProcMgr_translateAddr: srcAddr [0x9c311ef0] dstAddr [0xe0f7cef0]

MemoryOS_map: pa=0x9c311ef4, va=0xe1236ef4, sz=0x4
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c311000]
    sgList.paddr  [0x9c311000]
    sgList.offset [0xef4]
    sgList.size [0xef8]

    ProcMgr_translateAddr: srcAddr [0x9c311ef4] dstAddr [0xe0f7cef4]

MemoryOS_map: pa=0x9c311ef8, va=0xe123cef8, sz=0x1d
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9c311000]
    sgList.paddr  [0x9c311000]
    sgList.offset [0xef8]
    sgList.size [0xf15]

    ProcMgr_translateAddr: srcAddr [0x9c311ef8] dstAddr [0xe0f7cef8]

    DM8168DSPPROC_start: Slave successfully started!

ElfLoader_getSymbolAddress: symName [_Ipc_ResetVector]

    ProcMgr_translateAddr: srcAddr [0x9c312400] dstAddr [0x9c312400]

    ProcMgr_translateAddr: srcAddr [0x9c312400] dstAddr [0xe0fec400]

    ProcMgr_translateAddr: srcAddr [0x9c31241c] dstAddr [0x9c31241c]

    ProcMgr_translateAddr: srcAddr [0x9c31241c] dstAddr [0xe0fec41c]

handle->slaveSRCfg[0].entryBase 9e400000

Platform_loadCallback:
    No SharedRegion.entry[0].cacheEnable configuration value found, using default FALSE

Platform_loadCallback:
    Mapping SharedRegion 0
    addr[ProcMgr_AddrType_MasterPhys] [0x9e400000]
    addr[ProcMgr_AddrType_SlaveVirt]  [0x9e400000]
    size                              [0x1000000]
    isCached                          [0]

MemoryOS_map: pa=0x9e400000, va=0xe2000000, sz=0x1000000
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9e400000]
    sgList.paddr  [0x9e400000]
    sgList.offset [0x0]
    sgList.size [0x1000000]

handle->slaveSRCfg[1].entryBase 9f400000

Platform_loadCallback:
    No SharedRegion.entry[1].cacheEnable configuration value found, using default FALSE

Platform_loadCallback:
    Mapping SharedRegion 1
    addr[ProcMgr_AddrType_MasterPhys] [0x9f400000]
    addr[ProcMgr_AddrType_SlaveVirt]  [0x9f400000]
    size                              [0xc00000]
    isCached                          [0]

MemoryOS_map: pa=0x9f400000, va=0xe4000000, sz=0xc00000
_ProcMgr_map for SlaveVirt:
    dstAddr       [0x9f400000]
    sgList.paddr  [0x9f400000]
    sgList.offset [0x0]
    sgList.size [0xc00000]

    ProcMgr_translateAddr: srcAddr [0x9c312400] dstAddr [0x9c312400]

    ProcMgr_translateAddr: srcAddr [0x9c312400] dstAddr [0xe0fec400]

Ipc_attach: Ipc_procSyncStart failed!
Ipc_attach: Ipc_procSyncStart failed!
OsalDrv_mmap(): setting cache disabled for physical address 9e400000

OsalDrv_mmap(): setting cache disabled for physical address 9f400000

    HeapMemMP_create knl ioctl: Shared addr [0xe2002e80]

    MessageQ_create: Max number of queues 32
    NameServer_getLocal name [MSGQ_03]
    NameServer_getLocal: Entry not found!
    NameServer_getLocal name [HeapMemMP30]
    MessageQ_open ioctl queueId [0x0]
    NameServer_getLocal name [MSGQ_30]
MessageQ_get
NameServer Module already initialized!
SharedRegion Module already initialized!
OsalDrv_mmap(): setting cache disabled for physical address 9e400000

OsalDrv_mmap(): setting cache disabled for physical address 9f400000

GateMP Module already initialized!
MessageQ Module already initialized!
HeapBufMP Module already initialized!
HeapMemMP Module already initialized!
ListMP Module already initialized!
ClientNotifyMgr Module already initialized!
FrameQBufMgr Module already initialized!
FrameQ Module already initialized!
Exit : grg_snd_soc_hw_params +65
Enter: sound/soc/codecs/pcm3501e.c +38
    NameServer_getLocal name [grg100015d4]
    NameServer_getLocal: Entry not found!
Failed to get value from remote NameServer
    NameServer_getLocal name [grg100015d4]
    NameServer_getLocal name [grg100015d4]
    NameServer_getLocal name [grg100015d2]
    NameServer_getLocal: Entry not found!
Failed to get value from remote NameServer
    NameServer_getLocal name [grg100015d2]
    NameServer_getLocal name [grg100015d2]
MessageQ_get
    NameServer_getLocal name [grg100015d2]
    NameServer_getLocal name [grg100015d4]
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
MessageQ_get
BUG: soft lockup - CPU#0 stuck for 61s! [kworker/0:1:24]
Modules linked in: syslink grg_gpio spi_uart_drv

Pid: 24, comm:          kworker/0:1
CPU: 0    Not tainted  (2.6.37+ #12)
PC is at _GT_1trace+0x28/0x58 [syslink]
LR is at GateMutex_enter+0x2c/0xa4 [syslink]
pc : [<bf04a85c>]    lr : [<bf04c554>]    psr: 80000013
sp : d8913da0  ip : 00030101  fp : d8913dac
r10: 00000004  r9 : c005f06c  r8 : 00000002
r7 : fa0ca800  r6 : 00000000  r5 : bf11b0e4  r4 : dca75000
r3 : dca75000  r2 : dca75000  r1 : 00050000  r0 : bf0c100c
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 980ac019  DAC: 00000017
[<c0043420>] (show_regs+0x0/0x50) from [<c0092560>] (watchdog_timer_fn+0xfc/0x150)
 r5:00000003 r4:18711a00
[<c0092464>] (watchdog_timer_fn+0x0/0x150) from [<c007fe50>] (__run_hrtimer+0x4c/0xc0)
[<c007fe04>] (__run_hrtimer+0x0/0xc0) from [<c0080144>] (hrtimer_interrupt+0x140/0x31c)
 r5:0000014b r4:00f97723
[<c0080004>] (hrtimer_interrupt+0x0/0x31c) from [<c004e828>] (omap2_gp_timer_interrupt+0x28/0x34)
[<c004e800>] (omap2_gp_timer_interrupt+0x0/0x34) from [<c0092a60>] (handle_IRQ_event+0x2c/0xec)
[<c0092a34>] (handle_IRQ_event+0x0/0xec) from [<c0094c44>] (handle_level_irq+0xac/0x11c)
 r7:fa0ca800 r6:00000000 r5:00000043 r4:c04a789c
[<c0094b98>] (handle_level_irq+0x0/0x11c) from [<c003707c>] (asm_do_IRQ+0x7c/0xa0)
 r5:00000000 r4:00000043
[<c0037000>] (asm_do_IRQ+0x0/0xa0) from [<c036a474>] (__irq_svc+0x34/0xa0)
Exception stack(0xd8913d58 to 0xd8913da0)
3d40:                                                       bf0c100c 00050000
3d60: dca75000 dca75000 dca75000 bf11b0e4 00000000 fa0ca800 00000002 c005f06c
3d80: 00000004 d8913dac 00030101 d8913da0 bf04c554 bf04a85c 80000013 ffffffff
 r5:fa200000 r4:ffffffff
[<bf04a834>] (_GT_1trace+0x0/0x58 [syslink]) from [<bf04c554>] (GateMutex_enter+0x2c/0xa4 [syslink])
[<bf04c528>] (GateMutex_enter+0x0/0xa4 [syslink]) from [<bf076964>] (GateHWSpinlock_enter+0x104/0x130 [syslink])
 r5:e1251000 r4:dca75000
[<bf076860>] (GateHWSpinlock_enter+0x0/0x130 [syslink]) from [<bf06b9d8>] (GateMP_enter+0x64/0xa0 [syslink])
 r7:e2001880 r6:00000000 r5:e1275000 r4:e1251000
[<bf06b974>] (GateMP_enter+0x0/0xa0 [syslink]) from [<bf06199c>] (ListMP_getHead+0xf4/0x2a4 [syslink])
 r5:e1275000 r4:bf11b0e4
[<bf0618a8>] (ListMP_getHead+0x0/0x2a4 [syslink]) from [<bf07aee8>] (_TransportShm_notifyFxn+0xb4/0xfc [syslink])
 r8:00000002 r7:e2001880 r6:00000000 r5:e1272000 r4:bf11b0e4
[<bf07ae34>] (_TransportShm_notifyFxn+0x0/0xfc [syslink]) from [<c02b08a8>] (notify_exec+0x9c/0xb0)
 r5:d8137800 r4:00000002
[<c02b080c>] (notify_exec+0x0/0xb0) from [<c02b2ee4>] (notify_shmdrv_isr_callback+0x98/0xac)
 r6:d77a1100 r5:e2001780 r4:00000000
[<c02b2e4c>] (notify_shmdrv_isr_callback+0x0/0xac) from [<c02b2f24>] (notify_shmdrv_dsp_isr+0x2c/0x3c)
 r7:00000000 r6:fffffffe r5:00000000 r4:00000002
[<c02b2ef8>] (notify_shmdrv_dsp_isr+0x0/0x3c) from [<c036c54c>] (notifier_call_chain+0x34/0x78)
 r5:00000000 r4:00000000
[<c036c518>] (notifier_call_chain+0x0/0x78) from [<c0081538>] (__blocking_notifier_call_chain+0x54/0x6c)
[<c00814e4>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c0081570>] (blocking_notifier_call_chain+0x20/0x28)
 r8:d8863a00 r7:c04a585c r6:d8913f34 r5:00000004 r4:d8a97a00
[<c0081550>] (blocking_notifier_call_chain+0x0/0x28) from [<c005f0b4>] (mbox_rx_work+0x48/0xec)
[<c005f06c>] (mbox_rx_work+0x0/0xec) from [<c0077798>] (process_one_work+0x1ec/0x318)
 r6:d88f1b40 r5:c04a5978 r4:d8a97a14
[<c00775ac>] (process_one_work+0x0/0x318) from [<c00780f0>] (worker_thread+0x1b4/0x2d0)
[<c0077f3c>] (worker_thread+0x0/0x2d0) from [<c007c3f0>] (kthread+0x8c/0x94)
[<c007c364>] (kthread+0x0/0x94) from [<c00687c4>] (do_exit+0x0/0x5e4)
 r7:00000013 r6:c00687c4 r5:c007c364 r4:d8847ee0
Kernel panic - not syncing: softlockup: hung tasks
Backtrace: 
[<c0045b40>] (dump_backtrace+0x0/0x110) from [<c03683f0>] (dump_stack+0x18/0x1c)
 r7:000000f7 r6:c04a6270 r5:00000003 r4:c04ccbd0
[<c03683d8>] (dump_stack+0x0/0x1c) from [<c0368454>] (panic+0x60/0x184)
[<c03683f4>] (panic+0x0/0x184) from [<c0092584>] (watchdog_timer_fn+0x120/0x150)
 r3:00000001 r2:00000001 r1:0000739f r0:c042542c
[<c0092464>] (watchdog_timer_fn+0x0/0x150) from [<c007fe50>] (__run_hrtimer+0x4c/0xc0)
[<c007fe04>] (__run_hrtimer+0x0/0xc0) from [<c0080144>] (hrtimer_interrupt+0x140/0x31c)
 r5:0000014b r4:00f97723
[<c0080004>] (hrtimer_interrupt+0x0/0x31c) from [<c004e828>] (omap2_gp_timer_interrupt+0x28/0x34)
[<c004e800>] (omap2_gp_timer_interrupt+0x0/0x34) from [<c0092a60>] (handle_IRQ_event+0x2c/0xec)
[<c0092a34>] (handle_IRQ_event+0x0/0xec) from [<c0094c44>] (handle_level_irq+0xac/0x11c)
 r7:fa0ca800 r6:00000000 r5:00000043 r4:c04a789c
[<c0094b98>] (handle_level_irq+0x0/0x11c) from [<c003707c>] (asm_do_IRQ+0x7c/0xa0)
 r5:00000000 r4:00000043
[<c0037000>] (asm_do_IRQ+0x0/0xa0) from [<c036a474>] (__irq_svc+0x34/0xa0)
Exception stack(0xd8913d58 to 0xd8913da0)
3d40:                                                       bf0c100c 00050000
3d60: dca75000 dca75000 dca75000 bf11b0e4 00000000 fa0ca800 00000002 c005f06c
3d80: 00000004 d8913dac 00030101 d8913da0 bf04c554 bf04a85c 80000013 ffffffff
 r5:fa200000 r4:ffffffff
[<bf04a834>] (_GT_1trace+0x0/0x58 [syslink]) from [<bf04c554>] (GateMutex_enter+0x2c/0xa4 [syslink])
[<bf04c528>] (GateMutex_enter+0x0/0xa4 [syslink]) from [<bf076964>] (GateHWSpinlock_enter+0x104/0x130 [syslink])
 r5:e1251000 r4:dca75000
[<bf076860>] (GateHWSpinlock_enter+0x0/0x130 [syslink]) from [<bf06b9d8>] (GateMP_enter+0x64/0xa0 [syslink])
 r7:e2001880 r6:00000000 r5:e1275000 r4:e1251000
[<bf06b974>] (GateMP_enter+0x0/0xa0 [syslink]) from [<bf06199c>] (ListMP_getHead+0xf4/0x2a4 [syslink])
 r5:e1275000 r4:bf11b0e4
[<bf0618a8>] (ListMP_getHead+0x0/0x2a4 [syslink]) from [<bf07aee8>] (_TransportShm_notifyFxn+0xb4/0xfc [syslink])
 r8:00000002 r7:e2001880 r6:00000000 r5:e1272000 r4:bf11b0e4
[<bf07ae34>] (_TransportShm_notifyFxn+0x0/0xfc [syslink]) from [<c02b08a8>] (notify_exec+0x9c/0xb0)
 r5:d8137800 r4:00000002
[<c02b080c>] (notify_exec+0x0/0xb0) from [<c02b2ee4>] (notify_shmdrv_isr_callback+0x98/0xac)
 r6:d77a1100 r5:e2001780 r4:00000000
[<c02b2e4c>] (notify_shmdrv_isr_callback+0x0/0xac) from [<c02b2f24>] (notify_shmdrv_dsp_isr+0x2c/0x3c)
 r7:00000000 r6:fffffffe r5:00000000 r4:00000002
[<c02b2ef8>] (notify_shmdrv_dsp_isr+0x0/0x3c) from [<c036c54c>] (notifier_call_chain+0x34/0x78)
 r5:00000000 r4:00000000
[<c036c518>] (notifier_call_chain+0x0/0x78) from [<c0081538>] (__blocking_notifier_call_chain+0x54/0x6c)
[<c00814e4>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c0081570>] (blocking_notifier_call_chain+0x20/0x28)
 r8:d8863a00 r7:c04a585c r6:d8913f34 r5:00000004 r4:d8a97a00
[<c0081550>] (blocking_notifier_call_chain+0x0/0x28) from [<c005f0b4>] (mbox_rx_work+0x48/0xec)
[<c005f06c>] (mbox_rx_work+0x0/0xec) from [<c0077798>] (process_one_work+0x1ec/0x318)
 r6:d88f1b40 r5:c04a5978 r4:d8a97a14
[<c00775ac>] (process_one_work+0x0/0x318) from [<c00780f0>] (worker_thread+0x1b4/0x2d0)
[<c0077f3c>] (worker_thread+0x0/0x2d0) from [<c007c3f0>] (kthread+0x8c/0x94)
[<c007c364>] (kthread+0x0/0x94) from [<c00687c4>] (do_exit+0x0/0x5e4)
 r7:00000013 r6:c00687c4 r5:c007c364 r4:d8847ee0

Thanks

Jibin

0 Arnie Reynoso over 13 years ago in reply to Jibin Scaria

TI__Expert 6860 points

Jibin,

It unclear from the error message what may be causing the CPU lock. What SysLink applications are you running? It seems you are running a MessageQ application (not RingIO). Is this a modified version of the MessageQ sample application shipped with SysLink? I need a bit more context to try and replicate the failure on my end.

Can you run any of the sample application provided with SysLink (MessageQ, RingIO, etc)? I want to make sure your SysLink was built correctly. Make sure you have the appropriate SysLink dependent component versions (e.g. SysBios, Ipc, CodeGenTools, etc). Check the SysLink Release Notes located at the root of your SysLink installation.

It seems you are running on a DM8148 (or similar). What Linux kernel version are you using?

Thanks,

0 Jibin Scaria over 13 years ago in reply to Arnie Reynoso

Intellectual 380 points

Hi,

In this scenario I have 4 RingIOs send/Recv packtes @ 20ms and 2 Messages From DSP to Arm @ 4 ms. This causes syslink to stuck @ 20th packet (20 * 20ms).

This problem is not there if I disable the Messages from DSP to ARM.

Also I ran the examples and they are working fine.

Is there any limitation on the rate or Number of RingIOs/Messages can be used? I am using 8148 DSP@500Mhz and ARM@600Mhz

Thanks

Jibin

0 Arnie Reynoso over 13 years ago in reply to Jibin Scaria

TI__Expert 6860 points

Jibin,

There is no limitation on the rate or number of RingIO or Message that can be used.

Are the RingIO packets and the MessageQ payload running in the same thread/task on either side? I'm trying to come up with an example that would mimic your scenario to see if I can replicated the issue. We don't typically validate running both MessageQ and RingIO in the same application, though there is no reason why this wouldn't work.

Are you registering a gate with your RingIO? If a gate is not registered in RingIO, it will used the default system gate that portions of SysLink rely on for protection thus might cause a resource contention that is lock something out. I can't confrim that this is happening but worth a mention.

Also worth mentioning, SysLink v2.10 has had some significant improvements/bug fixes in RingIO versus the v2.00. One caution though, the newer version requires newer set of dependencies (e.g. SysBios, XDCTools, IPC) that may not be fully compatible with some of the other system software you may have. Take a look at the SysLink release notes for more info.

Future EZSDK will eventually migrate to the 2.10 version of SysLink.. You can find the latest SysLink releases at:

">http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/index.html

0 Arnie Reynoso over 13 years ago in reply to Arnie Reynoso

TI__Expert 6860 points

Re-posting broken link above.

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

0 Jibin Scaria over 13 years ago in reply to Arnie Reynoso

Intellectual 380 points

Hi Arnie,

Thanks for your reply.

I am using multiple tasks with four RingIOs & MessageQ in DSP and In ARM messageQ is handled in one task and all RingIOs are handled in another task with two RingIOs in each thread as shown below.

DSP ARM

===== ========

Main Task <--- MessageQ1---> Main Task

__________

| MessageQ1---> Sub Task1

| <---RingIO1 Thread1

Sub Task1 | RingIO2--->

| <---RingIO3 Thread2

| RingIO4-->

__________|

__________

| MessageQ1---> Sub Task1

| <---RingIO5 Thread3

Sub Task2 | RingIO6--->

| <---RingIO7 Thread4

| RingIO8-->

__________|

Is there any design issues in my app? I am not registering any gate with the ringIOs. How can I do that?

These are the module versions that I am using.

bios_6_32_01_38

ipc_1_23_03_31

syslink_2_10_02_17

xdctools_3_23_00_32

Thanks

Jibin

0 Ramsey over 13 years ago in reply to Jibin Scaria

TI__Genius 12025 points

Jibin,

Just a quick observation. From your description above, it looks like you are sharing the same message queue between two tasks, MessageQ1 with Task1 and Task2. The IPC API's are *not* thread safe. For example, you cannot have two tasks simultaneously calling MessageQ_put, or any other API function. If you want two tasks both sending messages to the same queue, be sure to add a gate in your code so only one task can call MessageQ_put at a time. It's okay to switch between two tasks as long as the calls have been serialized.

A point of clarification. Message queues exist only on one processor, not in-between two processors. For example, the ARM might have a queue called MessageQ1 but that same queue cannot exists on the DSP as well. There are typically many writers (MessageQ_put) but only one reader (MessageQ_get). To send messages back and forth requires two queues, one on each core to receive inbound messages. Your diagram would indicate there is one queue called MessageQ1 which is used by DSP:MainTask and ARM:MainTask to send messages both ways. That is not possible.

~ Ramsey

0 Arnie Reynoso over 13 years ago in reply to Ramsey

TI__Expert 6860 points

Jibin,

The source of your issue might be releated to your use of MessageQ as Ramsey stated.

Just to complete your previous questions, you can register a gate with RingIO. Take a look at the RingIO samples application for the ARM (ti/syslink/samples/hlos/ringio/RingIOApp.c) to see how the RingIO instance is being created with the GateMP handle.

0 Jibin Scaria over 13 years ago in reply to Arnie Reynoso

Intellectual 380 points

Hi Arnie/Ramsey,

I have tried Gate to protect messageQ in DSP and registered Gates with ringIOs. But looks like after this change system gets locked up in gateMP_enter. Sometime the ARM is halting for few seconds and continues execution again.

Is is possible to get more info on GateMP usage and performance. Looks like syslink IPC frame work is not good for any real-time application where many ringIOs and messageQs are used.

Thanks

Jibin

0 MUGDHA ARORA over 13 years ago in reply to Ramsey

Genius 4120 points

Ramsey said:

Just a quick observation. From your description above, it looks like you are sharing the same message queue between two tasks, MessageQ1 with Task1 and Task2. The IPC API's are *not* thread safe. For example, you cannot have two tasks simultaneously calling MessageQ_put, or any other API function. If you want two tasks both sending messages to the same queue, be sure to add a gate in your code so only one task can call MessageQ_put at a time. It's okay to switch between two tasks as long as the calls have been serialized.

This is not true ... MessageQ_put can be called simultaneously from any number of threads (or processes). No additional protection is needed in the application. In fact, adding protection incorrectly could cause deadlocks.

Ramsey said:

A point of clarification. Message queues exist only on one processor, not in-between two processors. For example, the ARM might have a queue called MessageQ1 but that same queue cannot exists on the DSP as well. There are typically many writers (MessageQ_put) but only one reader (MessageQ_get). To send messages back and forth requires two queues, one on each core to receive inbound messages. Your diagram would indicate there is one queue called MessageQ1 which is used by DSP:MainTask and ARM:MainTask to send messages both ways. That is not possible.

This is correct. MessageQ is different from the other IPCs in the sense that it's a 'local' MessageQ. The transport underneath allows different processors to send messages to this local queue. For example, a MessageQ created on DSP resides fully on the DSP, and any threads on DSP can send messages to it. Any threads on any other processor can also send messages to it using the same MessageQ_put API, as long as the transport connection exists between the DSP and that other processor. This transport configuration happens for you automatically when you configure IPC correctly in your CFG file (including MessageQ as enabled) and call Ipc_attach. This, you must be doing already, otherwise you wouldn't have seen anything working.

Regards,
Mugdha

0 MUGDHA ARORA over 13 years ago in reply to Jibin Scaria

Genius 4120 points

Jibin,

The only problem I see with your scenario is your usage of MessageQ1 as a reader from two threads on the ARM. That is not permitted. MessageQ can have only 1 reader. If you need to send messages to another thread on the ARM, you need to create a separate MessageQ. So essentially, you need 3 Message Queues as per your diagram:

1. DSP -> ARM - Main Task

2. ARM -> DSP - Main Task

3. DSP -> ARM - Sub task 1

The RingIO usage seems fine.

Are you sure any protection you are using on top of these module usage is not causing deadlock in protection across the tasks?

Are you doing anything in the ISR (RingIO callback), such as calling any other IPC APIs? That could cause problems or deadlocks. In callback, you should just quickly post a semaphore or something and do the actual work in a task.

Regards,
Mugdha

0 Jibin Scaria over 13 years ago in reply to MUGDHA ARORA

Intellectual 380 points

Hi Mugdha,

Thanks for the reply. Sorry for the confusion in the architecture. Please see the picture below

MugdhaK said:
Are you sure any protection you are using on top of these module usage is not causing deadlock in protection across the tasks?

ARM: There is no task wide protection. But I created GateMP for each RingIO instances

DSP: For MessageQ I added Gate enter/leave around messageq_put after Ramsey's reply

MugdhaK said:
Are you doing anything in the ISR (RingIO callback), such as calling any other IPC APIs? That could cause problems or deadlocks. In callback, you should just quickly post a semaphore or something and do the actual work in a task.

I am just posting one semaphore to the Thread from the Rio callback.

Thanks

Jibin

0 MUGDHA ARORA over 13 years ago in reply to Jibin Scaria

Genius 4120 points

Jibin,

This architecture looks good.

1. Please remove the protection around the MessageQ_put calls. Since you seem to be facing some kind of GateMP deadlock, it's better to remove all unnecessary protection.

2. Are you able to debug on the DSP-side? If yes, can you check what's happening on the DSP when the ARM gets the cpu lock up bug notice? This indicates that the DSP took a GateMP lock and then hanged/crashed (or maybe fell into some infinite loop). Hence the ARM finds the GateMP lock always locked. The lock you're getting a hang on is the system lock, which is used by MessageQ module. So if you have ensured that the RingIOs have a separate GateMP lock and are not using the same system lock as is used by MessageQ, then it proves that the issue is with the system gate which is used with MessageQ. Then you can ignore the RingIO part and focus on MessageQ usage only.

3. You mentioned that you don't face an issue if you remove the MessageQ part and only have the RingIO. Have you checked the reverse as well? i.e. having only the MessageQ part and removing the RingIO? If you still face the issue, it might be easier to debug, and would clarify whether the issue is because of the loading due to RingIOs, or some basic issue in the application's usage of Message or some configuration issue.

Regards,

Mugdha

0 Jibin Scaria over 13 years ago in reply to MUGDHA ARORA

Intellectual 380 points

Hi Mugdha,

I think the problem, as you said, is in MessageQ. I have the following observations on messageQ without any RingIOs.

I started one main task + 8 sub tasks. the sub tasks are sending one message to arm in 1 sec interval. The messages I am getting in ARM has the following behaviours

Number of DSP Tasks Message Received from DSP tasks in ARM

--------------------------------------------------------------------------------------------------------------

0 0

1 0

2 0

3 1,2,3

4 0

5 0,1,5

6 0,1,2,3,4,5,6

7 3

The behavior is same with or without gate lock for MessageQ_put in DSP, but instead of task 0 I got message from other tasks and the number of tasks responding remains the same.

I started my coding from the MessageQ example in the syslink. The messageQ initialization code is same as in the example.

Thanks

Jibin

0 MUGDHA ARORA over 13 years ago in reply to Jibin Scaria

Genius 4120 points

Jibin,

Trying to make sure I understand the above ... are you saying that when you had 1, 2, 4 tasks on the DSP, you only got the message from DSP task 0 on ARM? And the only time you got all the messages that you expected was when you had 6 tasks? This definitely looks like some problem in MessgaeQ module usage ... MessageQ module would never miss sending or receiving messages. So if you're missing them, then something is wrong in the usage.

Where do you get the message from? Are you using the default SharedRegion0 heap? Are you allocating one message for each DSP task before you call MessageQ_put? And what happens after that to the message? Do you free it after receiving it on the ARM? And that's how the DSP task is able to allocate the next message to send? What are your message contents? Is it just the header, or do you have more data contiguous after the header, or does your header hold a pointer to actual data elsewhere? Are you doing any cache operations?

Regards,
Mugdha

0 Jibin Scaria over 13 years ago in reply to MUGDHA ARORA

Intellectual 380 points

Hi Mugdha,

MugdhaK said:
... are you saying that when you had 1, 2, 4 tasks on the DSP, you only got the message from DSP task 0 on ARM? And the only time you got all the messages that you expected was when you had 6 tasks?

Yes.

MugdhaK said:
Where do you get the message from? Are you using the default SharedRegion0 heap?

I am allocating in DSP. Please see code below

#define IPC_HEAP_MSGSIZE    128
#define IPC_HEAP_NUMMSGS    100
#define IPC_HEAPID          0

	msgLoad = MessageQ_alloc(IPC_HEAPID, IPC_HEAP_MSGSIZE);

	System_printf(GRG_DSP_CHANNEL_NAME "Load_getCPULoad = %d\n",u32Load);
	if(msgLoad != NULL)
	{
		grgmsg = (SYSLINK_MSGQ_MSG *)msgLoad;
		pstrStatusMsg = (DSP_STATUS_MSG *)grgmsg->payload;
		pstrStatusMsg->strIPCHeader.u32GrgSessionId = u32SessionId;
		pstrStatusMsg->strIPCHeader.u32MessageId = eDSP_CPU_LOAD_RES_MSG_ID;
		pstrStatusMsg->s32Status = u32Load;

		s32Ret = MessageQ_put(remoteQueueId, msgLoad);
		if (s32Ret != MessageQ_S_SUCCESS) {
			System_printf("MessageQ_put had a failure/error\n");
		}
	}

The configuration parameters are same as MessageQ example.


MugdhaK said:
Are you allocating one message for each DSP task before you call MessageQ_put?

yes.


MugdhaK said:
And what happens after that to the message? Do you free it after receiving it on the ARM?

Yes.

        s32Ret = MessageQ_get(messageQ, &msgRx, MessageQ_FOREVER);
        if (s32Ret != MessageQ_S_SUCCESS)
        {
            grgPrintf (eGRG_ERR, "This should not happen since timeout is forever\n");
        }

      //Process msgX

      s32Ret = MessageQ_free(msgRx);


MugdhaK said:
And that's how the DSP task is able to allocate the next message to send?

Can you explain it? I have given/allocated 100 Msg size in MessageQ when created.


MugdhaK said:
What are your message contents? Is it just the header, or do you have more data contiguous after the header, or does your header hold a pointer to actual data elsewhere?

Yes. The message has 12 bytes of data. As you can see in the above code. But no pointers


MugdhaK said:
Are you doing any cache operations?

No.

Thanks

Jibin

0 MUGDHA ARORA over 13 years ago in reply to Jibin Scaria

Genius 4120 points

Jibin Scaria said:

I am allocating in DSP. Please see code below

#define IPC_HEAP_MSGSIZE    128
#define IPC_HEAP_NUMMSGS    100
#define IPC_HEAPID          0

	msgLoad = MessageQ_alloc(IPC_HEAPID, IPC_HEAP_MSGSIZE);

	System_printf(GRG_DSP_CHANNEL_NAME "Load_getCPULoad = %d\n",u32Load);
	if(msgLoad != NULL)
	{
		grgmsg = (SYSLINK_MSGQ_MSG *)msgLoad;
		pstrStatusMsg = (DSP_STATUS_MSG *)grgmsg->payload;
		pstrStatusMsg->strIPCHeader.u32GrgSessionId = u32SessionId;
		pstrStatusMsg->strIPCHeader.u32MessageId = eDSP_CPU_LOAD_RES_MSG_ID;
		pstrStatusMsg->s32Status = u32Load;

		s32Ret = MessageQ_put(remoteQueueId, msgLoad);
		if (s32Ret != MessageQ_S_SUCCESS) {
			System_printf("MessageQ_put had a failure/error\n");
		}
	}

What is the structure of your message? Can you post that? Definitions of SYSLINK_MSGQ_MSG, DSP_STATUS_MSG.

You said:


Jibin Scaria said:


What are your message contents? Is it just the header, or do you have more data contiguous after the header, or does your header hold a pointer to actual data elsewhere?

Yes. The message has 12 bytes of data. As you can see in the above code. But no pointers

[/quote]

But in the above code, you seem to be setting pstrStatusMsg to a field called 'payload' in the message, and then dereferencing pstrStatusMsg as well. If you have any indirections from your message, then you'd need to do cache operations on those. Posting your message structure here would help in understanding this.

Regards,
Mugdha

0 Jibin Scaria over 13 years ago in reply to MUGDHA ARORA

Intellectual 380 points

Hi Mugdha,

This is the structure I am using.

#define IPC_MSG_PAYLOAD_SIZE    96

#define IPC_HEAP_MSGSIZE    128

#define IPC_HEAP_NUMMSGS    100
#define IPC_HEAPID          0

typedef struct
{
    MessageQ_MsgHeader header;
    char payload[IPC_MSG_PAYLOAD_SIZE];
}SYSLINK_MSGQ_MSG;

Thanks

Jibin

0 MUGDHA ARORA over 13 years ago in reply to Jibin Scaria

Genius 4120 points

Jibin,

This could be your problem. You are assuming that char is 8-bits. But char is 8 bits on ARM, but 16-bits on DSP (the data-bus is 16-bits wide). This causes a mismatch between ARM & DSP. Hence you should never define char in a shared structure. If you need it, you should define fully qualified type (UInt16). Hence you should use the following:

#define IPC_MSG_PAYLOAD_SIZE    ((128 - sizeof (MessageQ_MsgHeader)) / sizeof (UInt16))

typedef struct
{
MessageQ_MsgHeader header;
UInt16 payload[IPC_MSG_PAYLOAD_SIZE];
}SYSLINK_MSGQ_MSG;

Because of this, your code might be resulting in corruption beyond the message boundary and causing issues.

Also, the second problem is that MessageQ itself only takes care of cache coherence upto the message header size. So you should take care of cache coherence for the remaining part.

i.e. call Cache_wbInv for the remaining part before MessageQ_put and Cache_inv for the remaining part of the message after MessageQ_get. In this case, it might not be a problem since you are within 128 bytes, and cache operations always take place on 128 byte boundaries and in cache lines (128 bytes). But your code (for correctness) must not assume this, and you should add a call:

Before MessageQ_put:

Cache_wbInv (msg, sizeof (SYSLINK_MSGQ_MSG), Cache_Type_ALL, TRUE);

After MessageQ_get:

Cache_inv (msg, sizeof (SYSLINK_MSGQ_MSG), Cache_Type_ALL, TRUE);

This will ensure cache coherence on the message is always taken care of.

Regards,
Mugdha

0 Jibin Scaria over 13 years ago in reply to MUGDHA ARORA

Intellectual 380 points

Hi Mugdha,

I called Cache_wbInv (grgmsg, sizeof (SYSLINK_MSGQ_MSG), Cache_Type_ALL, TRUE); before put and Cache_inv (msgRx, sizeof (SYSLINK_MSGQ_MSG), Cache_Type_ALL, TRUE); after get in ARM side.

and

called Cache_wbInv (msgLoad, sizeof (SYSLINK_MSGQ_MSG), TRUE, NULL); before put and Cache_inv (msg, sizeof (SYSLINK_MSGQ_MSG), TRUE, NULL); after get in DSP side.

But the message received in DSP is not correct. So I am not able to communicate to DSP tasks.

With my earlier implementation I could get messages from all tasks (when there were 6 tasks). How can we explain that behavior?

Thanks

Jibin

0 MUGDHA ARORA over 13 years ago in reply to Jibin Scaria

Genius 4120 points

Jibin,

Did you also fix the problem with the format of the shared message structure (char)? If you don't fix that, the message contents you receive will not be as expected by the DSP. Also, it could cause corruption in other messages.

Jibin Scaria said:

With my earlier implementation I could get messages from all tasks (when there were 6 tasks). How can we explain that behavior?

I can't explain it ... Luck?

Regards,
Mugdha

0 Jibin Scaria over 13 years ago in reply to MUGDHA ARORA

Intellectual 380 points

Hi Mugdha,

In my architecture The DSP tasks are dynamically created when required by the arm application. The DSP sub task will do the following oprations

1. Setup Syslink

2. Open 4 RingIOs

3. Register Notifies for ringIOs

4. Start data transfer

5. -- Do data transfer based on notification from ARM --

6. Stop data transfer

7. Unregister notifies

8. Close ringIOs

9. destroy syslink

10. exit

The RingIOs are created by the ARM Main Task and Threads will Open whenever required.

I am seeing the following behavior (I did the test with messages disabled)

Case 1.

Start sub task 1

close sub task 1

Start sub task 2

close sub task 2

....

Working without any issues

Case 2.

Start sub task 1

Start sub task 2

Start sub task 3

Close a sub task -- RingIO close/notify unregister gives error and task will retry indefinitly

Start sub task 4 - DSP and ARM will hang for ever .. (In JTAG the GateMP enter/leave functions are visible.)

It looks like if there is any active data transfer in any RingIO, I cannot do any Close/Destroy/Unregister operations and sometime Open/Register. Is this correct?

I am using ringio notification for each packet (@ 20 ms, all the 4 ringios in one task with send/recv on packet)

Can you help on this?

Thanks

Jibin

0 MUGDHA ARORA over 13 years ago in reply to Jibin Scaria

Genius 4120 points

Jibin,

The second scenario also ought to work ... I think someone from the SysLink team would have to support you further on this to see if there is any issue in the application or the SysLink RingIO module.

Regards,
Mugdha

Processors

Processors forum

Syslink Ringio Creation crash