question about MessageQ_alloc

I think it is blocked in OSA_mutexLock(&gSystem_ipcObj.msgQLock); not in MessageQ_alloc.Can you confirm by adding more prints

hello SuperMan-Badri,

after testing, I found that 

It hang on MessageQ_get() due to timeout is forever, which cause the OSA_mutexUnlock() not be executed and the next command will be blocked in OSA_mutexLock

Did you have any comment about this situation?

...

if (OSA_TIMEOUT_FOREVER == timeout)
{
timeout = MessageQ_FOREVER;
}

do {
status = MessageQ_get(gSystem_ipcObj.selfAckMsgQ, (MessageQ_Msg*)&pAckMsg, timeout);

...

It means the remote core is not responding with ack message which can happen if remote core is crashed.

hello SuperMan-Badri,

But I didn't see CCS_CRASH_DUMP_XXX.. file. Does it have any meaning??

hello SuperMan-Badri,

more thing I found

1. the video on HDMI monitor is gone

2. I use  Vsys_getCoreStatus to get the status, and there's no response...

attach is more info. Any comment??

hello super-badri,

Did you have any idea about how to know which core was crashed when without CCS_CRASH_DUMP_XXX file?? 

If HDMI is blanked out M3VPSS is crashed as I previously mentioned.

hello Super-badri,

Int32 System_linkControl(UInt32 linkId, UInt32 cmd, Void *pPrm, UInt32 prmSize, Bool waitAck)

{

procId = SYSTEM_GET_PROC_ID(linkId);

printf(" SYSTEM: proc ID ( procID = %d, linkID = 0x%08x, cmd = 0x%08x) \r\n", procId, linkId, cmd);

..}

in the above function,

procID=1 means which processor ??

procID=2 means which processor ??

where can I found the command for each processor??

I found processor id mapping in system_linkId.h

#define SYSTEM_PROC_DSP (0)
/**< DSP Proc ID */

#define SYSTEM_PROC_M3VIDEO (1)
/**< Video M3 Proc ID */

#define SYSTEM_PROC_M3VPSS (2)
/**< VPSS M3 Proc ID */

#define SYSTEM_PROC_HOSTA8 (3)
/**< A8 Proc ID */

command mapping was under ./dvr_rdk/mcfw/interfaces/link_api/*.h

thanks...

hello Badri,

    Did you know who generate "CCS_CRASH_DUMP_XXX"??  A8? M3? or DSP?

By checking, CCS_CRASH_DUMP_XXX was generated in A8 and only for M3 (eg.CCS_CRASH_DUMP_XXX_M3. )....

Because A8 didn't got the event from remote core, I didn't see the file...

hello badri,

Did you know if there's any debug info we can get from the remote core directly?? like the signal (SIGXXX) in A8.

Sometimes the msgQ may be blocked and no more messages was provided...

When  there is h/w or s/w exception causing slave core to crash it will send an event to A8 VSYS_EVENT_SLAVE_CORE_EXCEPTION.If you have not received the event your application may not have registered for event callbacks. Anyhow you can confirm If VPSS M3 is crashed by calling Avsync_getWallTime and if you don't see the time getting incremented for more than 100ms it indicates VPSS M3 is crashed.

Super badri,

Anyhow you can confirm If VPSS M3 is crashed by calling Avsync_getWallTime and if you don't see the time getting incremented for more than 100ms it indicates VPSS M3 is crashed.

Q1. did you mean I can put Avsync_getWallTime() inside a task like M3VPSS_main() and print the result to confirm? right?

Q2. this is for VPSS M3,  And how about VIDEO M3 and DSP ?

Jack1234 said:

Q1. did you mean I can put Avsync_getWallTime() inside a task like M3VPSS_main() and print the result to confirm? right?

 - I mean call Avsync_getWallTime from A8.

Finding which core is not responding is straightforward. Whichever remote core is not responding to Message is crashed. If you want to moditor continuously enable

/dvr_rdk/mcfw/interfaces/link_api/system_debug.h

#define SYSTEM_PRINT_RT_AVG_STATS_LOG

This will cause each link to periodically print the average statistics on console.If some core has crashed it will stop printing.

Hello Super-Super Badri,

Till now, we know the ack message feedback from VPSS is gone. It looks like something wrong in VPSS.

But how did we know where the problem inside VPSS is??

If you have a crash dump file some analysis is possible.Without that only option is to use CCS+JTAG to connect to target VPSS M3 and examine the state of the core.

hello super-badri,

According to our previous discussion, I found the ACK of remote core is sent by Utils_tskAckOrFreeMsg() inside SystemLink_tskMain.

after looking into Utils_tskAckOrFreeMsg(), I got

retVal = Utils_quePut(pMsg->ackQue, pMsg, BIOS_WAIT_FOREVER);

I found that if the queue is always full, then it may block in following

handle->blockedOnPut = TRUE;
semPendStatus = Semaphore_pend(handle->semWr, timeout);

Although I send messages among A8/DSP/M3 very often, it should n't happen. Right?

Is there anything I miss?

Que full condition indicates core has crashed.

hello Badri-hero,

is there any way to avoid or what can I do in this case?

If core has encountered a s/w exception you should resolve that first.There is no way to avoid queue full condition when system has crashed