https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_16/fi-bsw-n3050/igt@gem_eio@in-flight-contexts-immediate.html (gem_eio:1711) CRITICAL: Test assertion failure function test_inflight_contexts, file ../tests/gem_eio.c:473: (gem_eio:1711) CRITICAL: Failed assertion: __check_wait(fd, obj[1].handle, wait) == 0 (gem_eio:1711) CRITICAL: error: -62 != 0 Subtest in-flight-contexts-immediate failed. https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_16/fi-bsw-n3050/igt@gem_eio@unwedge-stress.html (gem_eio:1391) CRITICAL: Test assertion failure function test_reset_stress, file ../tests/gem_eio.c:634: (gem_eio:1391) CRITICAL: Failed assertion: __check_wait(fd, obj.handle, 100e3) == 0 (gem_eio:1391) CRITICAL: error: -62 != 0 Subtest unwedge-stress failed.
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_25/fi-kbl-r/igt@gem_eio@reset-stress.html
Also seen on glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4087/shard-glk1/igt@gem_eio@in-flight-contexts-immediate.html
Used to happen at least once a week. Last seen was CI_DRM_4165_full (1 month, 1 week / 683 runs ago). Closing!
Guess who's back: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4435/shard-glk4/igt@gem_eio@in-flight-contexts-immediate.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/shard-glk7/igt@gem_eio@in-flight-contexts-immediate.html (gem_eio:1188) CRITICAL: Test assertion failure function test_inflight_contexts, file ../tests/gem_eio.c:518: (gem_eio:1188) CRITICAL: Failed assertion: __check_wait(fd, obj[1].handle, wait) == 0 (gem_eio:1188) CRITICAL: error: -62 != 0 Subtest in-flight-contexts-immediate failed.
The key clue here is that we spawn a thread to inject the GPU reset, and in that thread we have a debug tale tell. That debug output is missing before we timeout -- ergo the reset thread is not being run. NOTOURFAULT, but still we need to be more graceful.
*** Bug 107404 has been marked as a duplicate of this bug. ***
commit 5d78c73d871525ec9caecd88ad7d9abe36637314 (HEAD, upstream/master) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 27 12:10:52 2018 +0100 igt/gem_eio: Measure reset delay from thread We assert that we complete a wedge within 250ms. However, when we use a thread to delay the wedging until after we start waiting, that thread itself is delayed longer than our wait timeout. This results in a false positive error where we fail the test before we even trigger the reset. Reorder the test so that we only ever measure the delay from triggering the reset until we wakeup, and assert that is in a timely fashion (less than 250ms). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105954 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Martin, OK to close?
(In reply to Francesco Balestrieri from comment #8) > Martin, OK to close? Yep! Thanks!
This bug is fixed. Last seen 3 months ago.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.