10-21-2014 06:00 PM
Anyone can help verify this log ?
LC/0/6/CPU0:Oct 21 12:08:49.394 BKK: cpp_driver1[149]: cpp_drv_show_in_fly_ipc_paks: Entering... cpp_id=1
LC/0/6/CPU0:Oct 21 12:08:49.395 BKK: cpp_driver1[149]: TCPU IPC Ch2 hw_wrptr: 169, sw_rdptr: 168, Ch3 hw_wrptr: 0, sw_rdptr: 0
LC/0/6/CPU0:Oct 21 12:08:49.395 BKK: cpp_driver1[149]: ****** Dump In Fly IPC Packet 1 ******
LC/0/6/CPU0:Oct 21 12:08:49.395 BKK: cpp_driver1[149]: Packet from client: cpp_cp_svr
LC/0/6/CPU0:Oct 21 12:08:49.396 BKK: cpp_driver1[149]: cpp_seqno = 0x147a3f1
LC/0/6/CPU0:Oct 21 12:08:49.396 BKK: cpp_driver1[149]: clnt_seqno = 0x3218375
LC/0/6/CPU0:Oct 21 12:08:49.396 BKK: cpp_driver1[149]: timestamp = Oct 21, 2014 12:07:06.167921
LC/0/6/CPU0:Oct 21 12:08:49.396 BKK: cpp_driver1[149]: IPC Packet (raw data):
LC/0/6/CPU0:Oct 21 12:08:49.396 BKK: cpp_driver1[149]: 0x003800000147a3f1 0x0000000010020000 0x0008002801080000 0x0000000000000000
LC/0/6/CPU0:Oct 21 12:08:49.396 BKK: cpp_driver1[149]: 0x0000006000000084 0x0000009000000001 0x0000000c893d2020 0x50b6c098400af458
LC/0/6/CPU0:Oct 21 12:08:49.396 BKK: cpp_driver1[149]: 0x0000000100380000 0x0147a3e800000000 0x0002000000080028 0x0108000000000000
LC/0/6/CPU0:Oct 21 12:08:49.397 BKK: cpp_driver1[149]: 0x0000000000000040 0x0000000000000008 0x0000000100000008 0x893cb00050b6c054
LC/0/6/CPU0:Oct 21 12:08:49.397 BKK: cpp_driver1[149]: IPC Packet Decode:
LC/0/6/CPU0:Oct 21 12:08:49.397 BKK: cpp_driver1[149]: ipc_length = 0x38
LC/0/6/CPU0:Oct 21 12:08:49.397 BKK: cpp_driver1[149]: ipc_queue_id = 0x0
LC/0/6/CPU0:Oct 21 12:08:49.397 BKK: cpp_driver1[149]: ipc_seqno = 0x147a3f1
LC/0/6/CPU0:Oct 21 12:08:49.397 BKK: cpp_driver1[149]: ipc_dep_group_cnt = 0x0
LC/0/6/CPU0:Oct 21 12:08:49.397 BKK: cpp_driver1[149]: ipc_dep_group = 0x0
LC/0/6/CPU0:Oct 21 12:08:49.397 BKK: cpp_driver1[149]: ipc_group_id = 0x0
LC/0/6/CPU0:Oct 21 12:08:49.398 BKK: cpp_driver1[149]: ipc_source = 0x1002
LC/0/6/CPU0:Oct 21 12:08:49.398 BKK: cpp_driver1[149]: ipc_flags = 0x0
LC/0/6/CPU0:Oct 21 12:08:49.398 BKK: cpp_driver1[149]: im_enum = 0x8
LC/0/6/CPU0:Oct 21 12:08:49.398 BKK: cpp_driver1[149]: im_length = 0x28
LC/0/6/CPU0:Oct 21 12:08:49.398 BKK: cpp_driver1[149]: im_flags = 0x1
LC/0/6/CPU0:Oct 21 12:08:49.398 BKK: cpp_driver1[149]: im_subtype = 0x8
LC/0/6/CPU0:Oct 21 12:08:49.398 BKK: cpp_driver1[149]: im_source = 0x0
LC/0/6/CPU0:Oct 21 12:09:53.431 BKK: cpp_driver1[149]: cpp_drv_show_in_fly_ipc_paks: Entering... cpp_id=1
LC/0/6/CPU0:Oct 21 12:09:53.431 BKK: cpp_driver1[149]: TCPU IPC Ch2 hw_wrptr: 169, sw_rdptr: 168, Ch3 hw_wrptr: 0, sw_rdptr: 0
LC/0/6/CPU0:Oct 21 12:09:53.431 BKK: cpp_driver1[149]: ****** Dump In Fly IPC Packet 1 ******
LC/0/6/CPU0:Oct 21 12:09:53.431 BKK: cpp_driver1[149]: Packet from client: cpp_cp_svr
LC/0/6/CPU0:Oct 21 12:09:53.431 BKK: cpp_driver1[149]: cpp_seqno = 0x147a3f1
LC/0/6/CPU0:Oct 21 12:09:53.431 BKK: cpp_driver1[149]: clnt_seqno = 0x3218375
LC/0/6/CPU0:Oct 21 12:09:53.431 BKK: cpp_driver1[149]: timestamp = Oct 21, 2014 12:07:06.167921
LC/0/6/CPU0:Oct 21 12:09:53.431 BKK: cpp_driver1[149]: IPC Packet (raw data):
LC/0/6/CPU0:Oct 21 12:09:53.432 BKK: cpp_driver1[149]: 0x003800000147a3f1 0x0000000010020000 0x0008002801080000 0x0000000000000000
LC/0/6/CPU0:Oct 21 12:09:53.432 BKK: cpp_driver1[149]: 0x0000006000000084 0x0000009000000001 0x0000000c893d2020 0x50b6c098400af458
LC/0/6/CPU0:Oct 21 12:09:53.432 BKK: cpp_driver1[149]: 0x0000000100380000 0x0147a3e800000000 0x0002000000080028 0x0108000000000000
LC/0/6/CPU0:Oct 21 12:09:53.432 BKK: cpp_driver1[149]: 0x0000000000000040 0x0000000000000008 0x0000000100000008 0x893cb00050b6c054
LC/0/6/CPU0:Oct 21 12:09:53.432 BKK: cpp_driver1[149]: IPC Packet Decode:
LC/0/6/CPU0:Oct 21 12:09:53.432 BKK: cpp_driver1[149]: ipc_length = 0x38
I found in Bug Search CSCty84132 (SIP-700 throws cpp_driver) and no workaround. Why this log appear and can clear or not ?
JK.
10-27-2014 05:51 AM
JK: if you're running any XR42 release you might be susceptible to that ddts.
fixed in 43.
The IPC message is sane, I dont see anything wrong with it, it could be a simple timeout in the response. That is what the ddts you reference fixes, it fixes the ipc timeout between the HAL (hardware abstraction layer) process that talks to the CPP_CP_SVR (the driver that takes messages from the HAL and programs the CPP chip).
It is not directly harmful, it could be a temporary glitch due to the strictness of the SW as it was in XR42.
If you're running XR 43 we need to look further.
xander
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide