<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - GPU HANG: ecode 9:0:0x86dfbff9, in Map-GL [6016], reason: Hang on render ring, action: reset" href="https://bugs.freedesktop.org/show_bug.cgi?id=111395#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - GPU HANG: ecode 9:0:0x86dfbff9, in Map-GL [6016], reason: Hang on render ring, action: reset" href="https://bugs.freedesktop.org/show_bug.cgi?id=111395">bug 111395</a> from <a class="email" href="mailto:yugang.fan@intel.com" title="yugang <yugang.fan@intel.com>"> yugang</a> <pre>also attached the init analysis from our side, thank you ''' GPU HANG: ecode 9:0:0x86dfbff9, in GNaviMap-GL [6016], reason: Hang on render ring, action: reset Active process (on ring render): GNaviMap-GL [6016], score 0 ERROR: 0x00000000 FAULT_TLB_DATA: 0x0000000c 0xbd1ddf68 ACTHD: 0x00000000 ffffaa9c <-- Instruction at this address is being parsed now by CS IPEHR: 0x79000002 <-- (head of the instruction which was parsed previously) -> "3DSTATE_DRAWING_RECTANGLE" Also, there no bit set in error reg. This means there is no pagefault problem (memory issue) at least. ACTHD is what we need to take a look at here because it helps to point to the actual 3D instructions being parsed by command streamer when GPU hang is detected. ACTHD value of “ACTHD: 0x00000000 ffffaa9c” points to the GPU instruction at the GTT space address, “0xffffaa9c” “0xffffaa9c" points to "0x79000002", which is same value with IPEHR. 0xffffaa98: 0x79000002: 3DSTATE_DRAWING_RECTANGLE 0xffffaa9c: 0x00000000: top left: 0,0 The 3DSTATE_DRAWING_RECTANGLE command is used to set the 3D drawing rectangle and related state. Possibility is GPU got hung while executing 3DSTATE_DRAWING_RECTANGLE or other instruction previously. We do not know it for sure, but we found 33 entries of 0x7b000005: 3DPRIMITIVE: fail sequential. One of this "fail" is right before 3DSTATE_DRAWING_RECTANGLE. This log tells what was on top of the RCS queue is 3DPRIMITIVE that is used to submit vertices to 3D pipeline. Assume this was invoked by glDrawArrays (or equivalent draw function). Below is one of them that Bad length 7 in (null), expected 6-6 0xffffca9c: 0x7b000005: 3DPRIMITIVE: fail sequential -> previously parsed 0xffffcaa0: 0x00000006: vertex count 0xffffcaa4: 0x00000004: start vertex 0xffffcaa8: 0x00000000: instance count 0xffffcaac: 0x00000001: start instance 0xffffcab0: 0x00000000: index bias 0xffffcab4: 0x00000000: MI_NOOP 0xffffcab8: 0x78260000: 3DSTATE_BINDING_TABLE_POINTERS_VS -> currently being parsed 0xffffcabc: 0x00000000: dword 1 0xffffcac0: 0x782a0000: 3DSTATE_BINDING_TABLE_POINTERS_PS 0xffffcac4: 0x00000840: dword 1 0xffffcac8: 0x782f0000: 3DSTATE_SAMPLER_STATE_POINTERS_PS 0xffffcacc: 0x00000860: dword 1 ''' and we could't do further analysis per materials in our hands, didn't see any abnormal in ring/batch buffer, e.g. empty buffer, invalid buffer length..., the hang may be caused by near by "ffffaa9c", but the instructions in buffer has no abnormal finding</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>