The crucial trick to reproduce the bug is that we need to have
a decent pile of active bos to retire. Because we unref the bo
after having it moved off the active list, our recursion depth
in fdo bug #42180 is limited by the number of active objects that
can retire at the same time.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42180
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow testdisplay to locate the sprite on the screen and potentially
scale it using different crtc width/height vs the source width/height
(determined by the resolution on the target pipe).
Also fix exit, making sure we properly disable all the planes.
Signed-off-by: Jesse Barnes <jbarnes@virtuougseek.org>
Provokes the forcewake warning when the hangcheck runs and no
one waits for the gpu (and hence holds the dev->struct_mutex).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We actually want to test lru behaviour, so do a bit of work with
the fence before yielding to the next thread (we use twice as many
fences as there are, so yielding always is pretty bad, no matter how
clever our fence stealing).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to docs, this should work with ppgtt and just convert to
noops otherwise. In reality, it hangs the machine.
So just disable these for the moment.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use the "ret" variable to check function return values, and these
values are not necessarily 0 on the successful cases, so we need to
reset "ret" after we finish using it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
getstats.c:48:2: warning: comparison of unsigned expression >= 0 is
always true
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems that the kernel patches required by the TEST_PLANES feature are
still not upstream, so I didn't test this patch.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If calls inside update_display fail, the function returns and we don't
quit the program if dump_info or test_all_modes. So we enter the main
loop and keep waiting for user input, even on cases where we are not
supposed to require user input. To fix this, we move the check to
outside the update_display function. As a side effect, we also do
cleanup instead of just exit(0) and we return 1 in case update_display
failed.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously, when called without any arguments, the application required
user input to finish. However, testdisplay is ran by "make check", and
it is not a good idea to run a program that requires user input in "make
check". So we change the default behavior to something that doesn't
require user input. You can still access the previous behavior using the
"-m" argument.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
testdisplay.c:117:1: warning: comparison between signed and unsigned
integer expressions
testdisplay.c:125:1: warning: comparison between signed and unsigned
integer expressions
testdisplay.c:145:1: warning: comparison between signed and unsigned
integer expressions
testdisplay.c:1060:16: warning: comparison between signed and unsigned
integer expressions
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Creating a zero-length bo should fail, so check that. Still run
the minimal batchbuffer, but without the zero-length reloc.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Hangs gen3 and simply writes garbage into the unmappable part of
gtt on gen4+, which might cause issues later on.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using a dummy reloc that doesn't matter to trick the kernel into
synchroizing the rings.
v2: properly apply MI_NOOP workaround to MI_FLUSH_DW and
switch to MI_COND_BATCH_BUFFER_END as a dummy command on the
render ring to avoid PIPE_CONTROL errata.
v3: somebody clever decided that in C, you cound from 1,
i.e. I915_EXEC_RENDER == 1. It works now ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also start to shortly explain testcases with an easily-greppable
header like this:
/*
* Testcase:
*
* [Possible further explanation.]
*
*/
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
MI_*/PIPE_CONTROL writes need to be in DOMAIN_INSTRUCTION, because
that is what mesa uses and I plan to use this to work around a
gen6 ppgtt issue.
Also testing with intentionally b0rked GFX_MODE on my snb shows that
we need to increase the loop counter a bit to reliably hit the tlb
invalidation problem. Test still completes within a few seconds.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously, "make check" failed because the main() function was not
defined.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a couple of simple store dword tests to test memory coherence.
gem_storedw_loop simply executes a batch that continually stores an
incremented value to a target buffer object, checking the results after
each batch completes.
gem_storedw_batches_loop does the same thing, but creates a new command
batch buffer for each iteration, which can exercise the buffer creation
code. This test is based on one from Andrzej Kacprowski from Intel.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
In other news: We've been missing a unmapping_mapping_range somewhere
in the kernel. But lazy me never came around to digging up the real
cause.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As signals cause the syscalls to be interrupted, we often need to clean
up partial state before returning to userspace. Often a source of
unamusing bugs, so encourage gem_stress to provoke them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gem_stress -p1 is much more evil than gem_stress -c1, it also manages
to tear appart untiled workloads!
Now duct-taping over it still works (--apply-duct-tape) ... hm.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
