<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - TF2: GPU lockup on HD 7950" href="https://bugs.freedesktop.org/show_bug.cgi?id=96271#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - TF2: GPU lockup on HD 7950" href="https://bugs.freedesktop.org/show_bug.cgi?id=96271">bug 96271</a> from <a class="email" href="mailto:julien.isorce@gmail.com" title="Julien Isorce <julien.isorce@gmail.com>"> Julien Isorce</a> <pre>Hi Stephen, if you still have the same machine/setup maybe worth to try the apitrace 1) that I mentioned here <a class="bz_bug_link bz_status_NEW " title="NEW - ring 0 stalled after bytes_moved_threshold reached - CAPVERDE/HD7770 - TAHITI/W9000" href="show_bug.cgi?id=100712#c7">https://bugs.freedesktop.org/show_bug.cgi?id=100712#c7</a> . I wonder if it is the same issue. About "dmesg_after_hard_hang.txt" / "kernel_log_during_gdm_restart.txt" all these exact same backtraces are happening because the ring 0(GFX) is still stuck after gpu reset. So acceleration is marked as disabled. But then mesa clear some buffers being cached before reset and it hits WARN_ON in radeon_ttm_bo_destroy, see <a href="https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/radeon/radeon_object.c?h=amd-staging-4.9#n72">https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/radeon/radeon_object.c?h=amd-staging-4.9#n72</a>. I recently submitted a patch to change it to a WARN_ON_ONCE. But the real problem is the ring 0 stalled in the first place. For me I found that setting R600_DEBUG=nowc workarounds the problem. Also I have not found any full dmesg log in the attachments, especially infos generated at startup.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>