【Qcom Camera】DumpDebugInfo分析

本文主要是介绍【Qcom Camera】DumpDebugInfo分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

DumpDebugInfo：

DumpDebugInfo主要包括Session::DumpDebugInfo、Pipeline::Dumpdebuginfo、Node::Dumpdebuginfo、DRQ::Dumpdebuginfo、Usecase::DumpDebugInfo

log：Hit SOF threshold of [xx] consecutive frames
      CamX: [ERROR][CORE ] camxpipeline.cpp:3248 CheckForRecovery() Hit SOF threshold of [17] consecutive frames with invalidrequestId; triggering watchdog recovery for pipeline RealTimeFeatureZSLPreviewRawYUV_0
      以上log表明kernel丢失连续的17帧，也意味着UMD 长时间没有向kernel发送sensor或 IFE request
ProcessCaptureRequest reset UMD
      CamX : [CONFIG][CORE ] camxsession.cpp:1689 ProcessCaptureRequest() Lets do a Reset:UMD
      当request queue已满时，Camx session需要等待至少一个live pending requests(待处理请求)完成。如果等待超时，就会出现以上log
      意味着所有live pending requests的result都没有完成。应该检查reslut是否卡在某个地方
Kernel requests recovery
       CamX : [ERROR][CSL ] camxcslhwinternal.cpp:1232 CSLHwInternalSendRequestManagerEvent() frame error: type 4, requestID 0, device hdl 0 04-10 00:12:39.463 11687 11689 E CamX : [ERROR][CORE ] camxpipeline.cpp:3435 CSLMessageHandler() request id 0, error type = 4, device handle = 0, resource index = 0
       首先check kernel问题
Flush timeout
      CamX: [ERROR][CORE ] camxsession.cpp:151 WaitTillFlushResultsAvailable() TimedWait for results timed out at 255 ms with error CamxResultETimeout! Pending results: 1249511 03-25 05:28:08:118452867 939 939 I CamX: [ DUMP][CORE ] camxsession.cpp:6108 DumpDebugInfo() + Stuck on Sequence Id: 201 Request Id: 87
      以上log表明flush 卡住，后面的session dump可能会有帮助

CamX : [ DUMP][CORE ] camxnode.cpp:8417 DumpDebugInfo() + Request: 1 Unsuccessful. metaComplete: 1, reqComplete: 0, numUnsigFences: 1, numUnprocFences: 1, status: SUBMIT , currTime 03:45:42:764 statusTransitionTime: 03:45:37:659
request:该node中未处理完成的request id
metaComplete:该request的meta是否处理完成。0表示没有处理完成，1表示处理完成
reqComplete: 该request的buffer是否处理完成。0表示没有处理完成，1表示处理完成
numUnsigFences: 该request中unsigned fences的个数，这个值随着 fence在node中被触发而减少。该值为0时，表示所有output都是可用的。
numUnprocFences：该request中的还没有处理的fence的个数
status：该request的状态

camxsession.cpp DumpDebugInfo
                   Stuck on Sequence Id: 0 Request Id: 1     //卡在了Request Id:
camxpipeline.cpp DumpDebugInfo
                   isSofdispatched: 0                        //sensor没有出帧（如果DRQ处于DEFERRED状态，也就是request尚未满足dependency，所以request还没有发到HW，需要再往下分析sensor node还有哪些dependency尚未满足）
                                                                              （如果DRQ处于SUBMIT状态，说明request已经提交给硬件，这时候就需要看sensor driver（kernel）的log，看是不是有硬件操作失败的相关log了）
                   numNodes: 23                              //request 要经过23个node处理
                   numNodesRequestIdDone: 22                 //request 已经在22个node处理完，还有一个没处理完
camxnode.cpp   DumpDebugInfo
                   status: SUBMIT    //request已经提交给硬件，说明这个request的相关依赖已经得到满足，并且执行了该node 的ExecuteProcessRequest，等待结果的返回
                   status: DEFERRED //说明当前node还缺少依赖的property或者buffer，相关request还没有发到HW
camxdeferredrequestqueue.cpp DumpDebugInfo()
                   Property[0] = 0x30000024 PropertyIDSensorProperties offset 18446744073709551615 contextType 0 on Pipeline = 0 is not published
                                      //在node上还没满足的是PropertyIDSensorProperties这个tag没有被publish出来。需要分析代码为什么这个property没有被published

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

-----------------------------------
发现连续丢帧 --> check session dump确定 first sutck的request --> Check pipeline dump确定出问题的pipeline以及first sutck的request和它的pending node
--> Check node dump看sensor 和IFE 分别stuck在哪里（sensor request n ready则IFE request n-1也必须ready 否则report invalid）确定丢帧是否因为UMD stuck,找到 deferred的request
--> Check 相应request的DRQ dump看它未满足的prop，确定这些prop由哪个node publish --> 继续追踪相应request 会publish prop的DRQ dump -->...

1.3.3 ISP apply fail Issue
Issue description
   Take a video with 4K@60fps, move the phone to keep the preview moving , and sometimes the preview freezes.(4K video 预览卡住)
Log analysis:
   1. Still recovery triggered by kernel consecutive invalid frames
   CamX : [ERROR][CORE ] camxpipeline.cpp:2698 CheckForRecovery() Hit SOF threshold of [17] consecutive frames with invalidrequestId; triggering watchdog recovery for pipeline PreviewVideo_0

   2. Always check sensor and IFE’s node dump for ‘Hit SOF threshold’ first
   CamX : [ DUMP][CORE ] camxsession.cpp:4960 DumpDebugInfo() + Stuck on Sequence Id: 1240 Request Id: 1241
   CamX : [ DUMP][CORE ] camxpipeline.cpp:3429 DumpDebugInfo() + Pipeline Name: PreviewVideo_0, Pipeline ID: 0, 0x7604a31800, CurrentRequestId: 1246

   //Pipeline PreviewVideo_0 is stuck on request 1241
   CamX : [ DUMP][CORE ] camxnode.cpp:4410 DumpDebugInfo() + NODE:[PreviewVideo_Sensor0]:Type:0 0x75da2ff6c0
   CamX : [ DUMP][CORE ] camxnode.cpp:4425 DumpDebugInfo() + Request: 1246 Unsuccessful. metadataComplete: 0, requestComplete: 0, numUnsignaledFences: 0, status: Deferred

   //Sensor:Request 1246 status deferred
   CamX : [ DUMP][CORE ] camxnode.cpp:4410 DumpDebugInfo() + NODE:[PreviewVideo_IFE0]:Type:65536 0x75f50195c0
   CamX : [ DUMP][CORE ] camxnode.cpp:4425 DumpDebugInfo() + Request: 1241 Unsuccessful. metadataComplete: 1, requestComplete: 0, numUnsignaledFences: 4, status: Submit

   //IFE:Request 1241 status Submit, but it still has 4 fences un-signaled
   3. 需要check IFE request 1241的fence为什么没有从kernel signal
   CAM_INFO: CAM-ISP: __cam_isp_ctx_epoch_in_applied: 1145 ctx:1 Report Bubble flag 1 req id:1238
   CAM_WARN: CAM-CRM: cam_req_mgr_process_trigger: 2290 Error recovery idx 1 status 1
   CAM_WARN: CAM-CRM: __cam_req_mgr_process_req: 1282 Err recovery done idx 1
   CAM_ERR : CAM-CRM: __cam_req_mgr_send_req: 565 APPLY FAILED pd 1 req_id 1241
   CAM_ERR : CAM-ISP: __cam_isp_ctx_apply_req: 4120 Apply failed in active substate 3
   //request 1238 Report Bubble,recovery done //ISP apply request 1241失败在它之后，并且没有为request 1241生成buffer,所以UMD不能获取request 1241的 IFE fence callbacks
Solution：
   Bubble and ISP apply 失败通常是因为performance低或者system schedule问题