<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Tonga GPU lock/reset fail with Unigine Valley" href="https://bugs.freedesktop.org/show_bug.cgi?id=91278#c33">Comment # 33</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Tonga GPU lock/reset fail with Unigine Valley" href="https://bugs.freedesktop.org/show_bug.cgi?id=91278">bug 91278</a> from <a class="email" href="mailto:master.homer@gmail.com" title="Mathias Tillman <master.homer@gmail.com>"> Mathias Tillman</a> <pre>(In reply to Andy Furniss from <a href="show_bug.cgi?id=91278#c32">comment #32</a>) > (In reply to Mathias Tillman from <a href="show_bug.cgi?id=91278#c31">comment #31</a>) > > Small update: I have been able to run it for a total of 7 hours (2 + 2 + 3) > > without a hang on the latest drm-next-4.4-wip. Tried the latest > > drm-fixes-4.3 and it hung after about 30 minutes, so I definitely think > > there's something in 4.4 that fixes it. I will do a bisect to see if I can > > figure out what, more exactly, is the fix. > > I'll try over the weekend - no locks so far. > > Bisecting would be a pain for me as I managed to very long lucky runs > previously, so wouldn't be able to easily call good. > > I notice that enable_scheduler is now on by default, maybe flipping that > would be quicker than bisect. Long ago I did try some older kernel with that > enabled and though it didn't fix IIRC it took longer to lock than was normal > at that time. Just ran it again with the scheduler disabled (from code, not through the module parameter) on 4.4-wip, and sure enough, after about 30 minutes it hung. So it looks like there's something in the scheduler that either makes it not happen as often, or not at all (will need to confirm this).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>