On CI_DRM_3011, the machine fi-glk-2a hit the following issue when running igt@kms_frontbuffer_tracking@basic: (kms_frontbuffer_tracking:3506) intel-batchbuffer-CRITICAL: Test assertion failure function intel_batchbuffer_flush_on_ring, file intel_batchbuffer.c:184: (kms_frontbuffer_tracking:3506) intel-batchbuffer-CRITICAL: Failed assertion: (drm_intel_gem_bo_context_exec(batch->bo, ctx, used, ring)) == 0 (kms_frontbuffer_tracking:3506) intel-batchbuffer-CRITICAL: Last errno: 5, Input/output error This appears to be due to the test igt@gem_exec_suspend@basic-s3 htting the WARN_ON(wait_for_engine(engine, 50)) (https://bugs.freedesktop.org/show_bug.cgi?id=102456) which led to a jammed GEM. Many tests just skip after that, but this test apparently is relying on GEM without testing for its availability using igt_require_gem. Full logs: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3011/fi-glk-2a/igt@kms_frontbuffer_tracking@basic.html
Changed component to igt since fixing needs to be done there...
Moving back. You do _not_ have to call igt_require_gem on an i915-only testcase, that's for intel-specific subtests in generic tests. Please never assign igt test failures to the igt component, that's just for tools and stuff like that. For testcases the default assumption must be that the kernel is broken. Which is the case here.
Also changing the summary, Martin is wrong here.
(In reply to Daniel Vetter from comment #3) > Also changing the summary, Martin is wrong here. And this is why we always need to trust the actual developers ;) Sorry that my guess was wrong!
Moving high as being sporadic
This needs to be reproduced by a developer. -EIO can result from a few places and none are obvious from the debug logs.
(In reply to Martin Peres from comment #4) > (In reply to Daniel Vetter from comment #3) > > Also changing the summary, Martin is wrong here. > > And this is why we always need to trust the actual developers ;) > > Sorry that my guess was wrong! No, you were spot on.
This issue was filed against a machine that is no longer in BAT. The issue has never been reproduced on the current GLK machine in BAT.
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.