SPRADI3 June 2024 AM625 , AM62P , AM67 , AM67A , AM68 , AM68A , AM69 , AM69A , DRA829J , DRA829J-Q1 , DRA829V , DRA829V-Q1 , TDA4AEN-Q1 , TDA4AH-Q1 , TDA4AL-Q1 , TDA4AP-Q1 , TDA4APE-Q1 , TDA4VE-Q1 , TDA4VEN-Q1 , TDA4VH-Q1 , TDA4VL-Q1 , TDA4VM , TDA4VM-Q1 , TDA4VP-Q1 , TDA4VPE-Q1
The GPU is equipped with a framework to identify issues in the graphics processing and issue hardware resets or recoveries to alleviate the symptoms. There are counters in the driver keeping track of the number of recoveries that have occurred. The cause of the hardware recovery (HWR) needs to be analyzed because these errors indicate a failure has occurred during GPU processing. GPU HWR logs have a standard look, and the easiest way to identify them is to look for the heading PVR in the logs. The logs outline some generic information in the console such as the driver version and build options. Logs also include more specific information relating to the crash. This data is dumped by the firmware in a standardized format that can be shared with TI to be analyzed. The relevant data needed for identifying the issue is not always available in these logs so the assigned engineer can request collecting the logs again with more verbosity and with modified drivers to get the necessary information.
There are cases when the GPU does not issue a HWR, but other messages related to the GPU driver are displayed and the GPU processing is affected. Similar to the previously-mentioned case, these logs need to be shared with TI for analysis, and can indicate other types of failures in the GPU driver. Section 2.6.1 is an example of a typical HWR.
An easy way to search for these is to
search for PVR in the dmesg
logs. The PVR Log Dump
Collection section describes how to collect these logs to share with
TI.