| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It's a compromise between detecting an unlikely timing error in one
test and being able to run a broader selection of tests. I hope this is
wise.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
commit e63a0681d95a ("tests/gem_close_race: Use drm_open_driver helper")
left a few raw open() behind. Eliminate them as well!
References: https://bugs.freedesktop.org/show_bug.cgi?id=96605
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Add docs, rename parameter and rename the macro to igt_do_timeout to
make it clear it works like a loop.
v2: Rename instead to igt_until_timeout (Chris).
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
igt_fork_hang_detector() was called from a igt_fixture block, while its
counterpart (igt_stop_hang_detector) was called normally, causing
SIGTERM to be sent when running under check target.
Signed-off-by: Marius Vlad <marius.c.vlad@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Marius Vlad <marius.c.vlad@intel.com>
|
|
Let's try it again because it would have caught a bug in a patch I sent
to the ml...
References: https://bugs.freedesktop.org/show_bug.cgi?id=95048
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Rather than create a new scratch buffer every pass, import the original
as this provides stress upon less commonly trod paths (i.e. handling
objects with many vma) as well as many objects in general.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Emulate the behaviour of the second thread killing fd at random by
having a signal fire at a random time instead. Only one thread and so we
do not have the issue of accessing another valid handle on another fd
and so executing a blank buffer - triggering GPU hangs.
References: https://bugs.freedesktop.org/show_bug.cgi?id=95048
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Currently this test causes some machines to hang and segfaults on others.
Rename it for now until we figure out the root cause.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95048
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Marius Vlad <marius.c.vlad@intel.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Add a header that includes all the headers for the library. This allows
reorganisation of the library without affecting programs using it and
also simplifies the headers that need to be included to use the library.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
|
|
The integer comparison macros give us better error output by including
the actual values that failed the comparison.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Increate the GPU load slightly, but mitigate the CPU overhead from
clflushing by keeping the object alive using flink. This has also the
side-effect of magnifying the desired busy-close race.
References: https://bugs.freedesktop.org/show_bug.cgi?id=71029
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The challenge here is to race GPU activity versus the gem_close. Using a
large objects makes the window of GPU activity larger - except on !llc
systems we then incur massive overhead from clflush, likely destroying
any race (due to mutex contention). And that mutex contention is
amplified by the number of cores - bad news for Baytrail.
Give up and make the objects smaller and hope that the test is run
frequently enough to catch the race.
References: https://bugs.freedesktop.org/show_bug.cgi?id=71029
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Brought a few missing headers to light in ioctl_wrappers.h, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Blows up otherwise if there's no intel gpu around.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73958
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With Full PPGTT, each new fd creates a new context and thus a new
PPGTT, so we have to reduce the number of simultaneous fds or face
OOM problems. For every new PPGTT, its PDEs are stored in the GGTT
which imposes a limit of 1024 new contexts. We want to leave at
least 1/4 of the GGTT available for "important" stuff like scanout
buffers, so never open more than 768 fds.
v2: Unconditionally use the lower limit, as suggested by Daniel
Vetter
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
In the past new testcases with subtest often forgot to add the call to
igt_exit at the end of their main() function. That is now caught with
a bit more obnoxious asserts, but it's still a nuissance.
This little igt_main macro takes care of that (and also of calling the
subtest machinery initialization code correctly).
If no one objects I'll roll this out for all the simple cases (i.e.
those tests that don't have additional argv parsing on top of the
subtest machinery).
v2: Roll it out across the board.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Emit more work per client and many more clients in order to increase the
chance of racing i915_gem_release() and i915_gem_retire_requests()
|
|
Pass the right pointer to the execlist would be a good start.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The intention is to exercise #70784. Yet the first challenge is make the
test suite happy.
|
