[Bug 102259] [CI][HSW] Failed assertion: !mismatch in igt at kms_cursor_legacy@flip-vs-cursor-busy-crc-(legacy|atomic)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=102259

--- Comment #12 from Marta Löfstedt <marta.lofstedt at intel.com> ---
IRC conversation about this for documentation:

<marta_> ickle, I have done some testing of your spibatch cleanup:
https://patchwork.freedesktop.org/patch/171768/ for
https://bugs.freedesktop.org/show_bug.cgi?id=102259
<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 at 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 at 6e644626
<ickle> "Forcing a modeset"
* jarit (~jtahvana at 134.134.139.82) has joined
* simonle1 (~Thunderbi at 192.55.54.42) 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 (~Thunderbi at 192.55.55.37) 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 at 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 at 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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170914/44bcb4bd/attachment.html>