<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][HSW] Failed assertion: !mismatch in igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-(legacy|atomic)" href="https://bugs.freedesktop.org/show_bug.cgi?id=102259#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][HSW] Failed assertion: !mismatch in igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-(legacy|atomic)" href="https://bugs.freedesktop.org/show_bug.cgi?id=102259">bug 102259</a> from <a class="email" href="mailto:marta.lofstedt@intel.com" title="Marta Löfstedt <marta.lofstedt@intel.com>"> Marta Löfstedt</a> <pre>IRC conversation about this for documentation: <marta_> ickle, I have done some testing of your spibatch cleanup: <a href="https://patchwork.freedesktop.org/patch/171768/">https://patchwork.freedesktop.org/patch/171768/</a> for <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][HSW] Failed assertion: !mismatch in igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-(legacy|atomic)" href="show_bug.cgi?id=102259">https://bugs.freedesktop.org/show_bug.cgi?id=102259</a> <marta_> you patch doesn't appear to help for BDW, also I still believe that the GPU_HANG is during test extecition and not afterwards. <marta_> spibatch -> spinbatch ... extecition -> execution <ickle> ok, just an issue elsewhere, the test isn't as nonblocking as it is supposed to be <ickle> oh, it doesn't use spinbatch anyway <ickle> so it can still be residual batches on the gpu <ickle> the other aspect is that a hang in the middle there isn't supposed to alter the crc <marta_> I am wondering why this only appear to bother HSW and BDW, so I was thinking that there was some issue with the bacth itself. <marta_> which could be easily tested... <ickle> the batch is nothing <ickle> it's just a means for making the plane update wait behind the scenes <marta_> I tested to remove everything between make_fb_busy and finish_fb_busy -> no GPU_HANG <marta_> good <marta_> next step only remove igt_pipe_crc_collect_crc(pipe_crc, &crcs[2]); --> no GPU_HANG * YuGiOhJCJ has quit (Quit: YuGiOhJCJ) <marta_> also, for completion I have previously concluded that by removing the whole busy thing there is no GPU_HANG * Notify: jsaa is online (Ubuntu Servers (freenode)) * jsaa (jsaa@nat/intel/x-iuwomztxdxwslqob) has joined <marta_> and what is even more puzzling to me is that for BDW this issue started with vsyrjalas drm-tip@6e644626 <ickle> "Forcing a modeset" * jarit (~<a href="mailto:jtahvana@134.134.139.82">jtahvana@134.134.139.82</a>) has joined * simonle1 (~<a href="mailto:Thunderbi@192.55.54.42">Thunderbi@192.55.54.42</a>) has joined <vsyrjala> modeset causes gpu hangs? <ickle> no, it's the test <ickle> the test doesn't like being blocked <ickle> it relies on the nonblocking interface in order to cancel the spinner and let the plane update proceed * jewins (~<a href="mailto:Thunderbi@192.55.55.37">Thunderbi@192.55.55.37</a>) has joined <vsyrjala> which test is that? maybe it shouldn't enable/disable crc capture during the critical section <ickle> that would be the easy fix <ickle> kms_cursor_legacy <ickle> flip_vs_cursor_crc() * jewins has quit (Remote host closed the connection) * _jewins (Thunderbir@nat/intel/x-wiswhomstokkdhzi) has joined <marta_> it is the flip-vs-cursor-busy-crc-(legacy|atomic) * _jewins has quit (Remote host closed the connection) * jewins (Thunderbir@nat/intel/x-oivcjudratazilmy) has joined <vsyrjala> i guess the main issue with not toggling crc capture all the time would be making sure it can deal with potentially getting multiple crcs at each step (in case something blocked it for more than a frame) <vsyrjala> and also making sure we look at the correct crc after a nonblocking commit</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>