<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing" href="https://bugs.freedesktop.org/show_bug.cgi?id=91880#c63">Comment # 63</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing" href="https://bugs.freedesktop.org/show_bug.cgi?id=91880">bug 91880</a> from <a class="email" href="mailto:jsbansen@gmail.com" title="Julian <jsbansen@gmail.com>"> Julian</a> <pre>Well, "fixed" :p I've used the patched module for 5-6 hours without issues now. So this version checks out. Next is with sclk_dpm_key_disabled = 0 and mclk_dpm_key_disabled = 0; My guess is that this'll make the freeze happen again. I've dug through the sources in an attempt to understand what's going on. My hypothesis is that the lockup happens under rare circumstances when the driver switches from one performance_level to another. Forcing the highest or lowest perf level is fine, but 'auto' switches perf levels often enough that the bug will happen relatively soon. At first I thought it was an issue with the writeback feature that caches certain register values because it also caches an rptr value that is used in the driver's gpu_lockup_check and is, to my knowledge, never actually written to. Buuut using radeon.no_wb=1 doesn't help. So if I've found a bug it is not the culprit of the lockups.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>