<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [GM45] loss of driver acceleration after some time (bisected)" href="https://bugs.freedesktop.org/show_bug.cgi?id=103025#c73">Comment # 73</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [GM45] loss of driver acceleration after some time (bisected)" href="https://bugs.freedesktop.org/show_bug.cgi?id=103025">bug 103025</a> from <a class="email" href="mailto:promarbler14@gmail.com" title="Adric Blake <promarbler14@gmail.com>"> Adric Blake</a> <pre>Getting back on track, I made a decent attempt at debugging the (underlying) bug that is responsible for these issues. Tested on kernel 4.18rc6+218. I reproduced the bug with full debug logging and drm.debug=0x1f. When the bug would occur, it would hit an assert that I have ignored in the xorg driver. Using the time of the assert, it is easy to line it up with the ioctl result listed in the kernel logs. I determined the execution of the ioctl by setting a logged global to certain values depending of the part of the code that gets run. Here is the trace of I915_GEM_SET_TILING ioctl: deepest/latest call last ioctl(I915_GEM_SET_TILING...) -> ret = -512 drm_ioctl_kernel(...) i915_gem_set_tiling_ioctl(...) i915_gem_object_set_tiling(...) i915_gem_object_fence_prepare(...) i915_vma_unbind(...) i915_gem_active_retire(...) i915_request_wait(...) -> ret = -ERESTARTSYS (512?) signal_pending_state(...) -> ret != 0 <uncertain core kernel code follows...> This is probably not the only kernel code path which causes the bug in the xorg driver. My bug replication method tends to only hit the bug on one path in the xorg driver, while a few other known paths get triggered by other uncertain uses (see the asserts that I ignore).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>