<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [bisected BYT] complete freeze after: drm/i915/vlv: WA for Turbo and RC6 to work together" href="https://bugs.freedesktop.org/show_bug.cgi?id=88012#c64">Comment # 64</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [bisected BYT] complete freeze after: drm/i915/vlv: WA for Turbo and RC6 to work together" href="https://bugs.freedesktop.org/show_bug.cgi?id=88012">bug 88012</a> from <a class="email" href="mailto:adf.lists@gmail.com" title="Andy Furniss <adf.lists@gmail.com>"> Andy Furniss</a> <pre>(In reply to Andy Furniss from <a href="show_bug.cgi?id=88012#c63">comment #63</a>) > (In reply to Maxime Bergeron from <a href="show_bug.cgi?id=88012#c62">comment #62</a>) > > (In reply to Andy Furniss from <a href="show_bug.cgi?id=88012#c61">comment #61</a>) > > > 8fb55197e64d5988ec57b54e973daeea72c3f2ff > > > drm/i915: Agressive downclocking on Baytrail > > > > > > reverted and I didn't lock, so it seems I messed up somewhere for that test > > > initially. > > > > > > So reverting above alone does make me stable on both the nightly I first > > > tested with and drm-intel-next-queued (tested as it was over the weekend). > > > > Maybe not. I just tried this (latest drm-intel-next-queued with the commit > > reverted) and I locked after ~2 hours uptime (couldn't get logs, everything > > hung up including ssh). Definitely more stable without the commit (less > > stutter in 1080p video playback), but I had over 50 hours of uptime with > > 4.0.0-RC6 without any issue. Maybe there's something wrong elsewhere ? > > Yea, I updated yesterday after seeing this and did manage to lock > next-queued. > > Possibly not anything recent, though, as it seems whether I lock or not now > depends on how I test - 1080i30 (+deint) with some 1080p60 on 60Hz display = > lock. I had been testing before with 1080p24 or 1080i25 and retried like > this today - it's still running after 9 Hours. > > Given the above the next commit I will try reverting in addition to > aggressive downclock = > > 6ad790c0f5ac55fd13f322c23519f0d6f0721864 > drm/i915: Boost GPU frequency if we detect outstanding pageflips > > and I will run samples where frame/field rate = refresh. Time passes - I had been slowly trying to find a guilty commit, but I gave up as the history for drm-intel-next-queued looks totally different depending where I am so it's hard to find anything. I can lock on the commit before Agressive downclocking on Baytrail but not with kodi - the only way I found was "make modules_install" which is quite strange - I made a prog that scrolls at variable rates but that didn't work. Trying to test with make going back in the history didn't get very far as I soon found that history is inconsistent due to the merges so I would test a commit (git reset --hard) fail, look at the history and choose an earlier commit then find that when reset on that the history was totally different and I was testing without the commits that "fixed" the issue in the first place c4d390d drm/i915: Use down ei for manual Baytrail RPS calculations 168ebd7 drm/i915: Improved w/a for rps on Baytrail even though the previous history/log had them way down after the new place I wanted to try.</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>