https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_174/fi-cfl-8109u/igt@gem_eio@unwedge-stress.html Starting subtest: unwedge-stress (gem_eio:2145) CRITICAL: Test assertion failure function check_wait, file ../tests/i915/gem_eio.c:258: (gem_eio:2145) CRITICAL: Failed assertion: elapsed < 250e6 (gem_eio:2145) CRITICAL: Wake up following reset+wedge took 252.632ms Subtest unwedge-stress failed.
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * CFL: igt@gem_eio@unwedge-stress - fail - Failed assertion: elapsed < 250e6 - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_174/fi-cfl-8109u/igt@gem_eio@unwedge-stress.html
The 250ms was a number plucked out of thin air. To perform a device reset takes around 10us, so I considered 250ms to have plenty of safety margin built in. In many ways, not being able to reset and restore control within a frame is a failure. So... I don't think I want to raise the timeout (with the exception of say pre-Ironlake where the display engine needs a couple of modesets) and keep looking for a likely root cause behind the occasional delay.
In this particular case, the delay corresponds to a pcieport error and a very slow timer interrupt.
The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore.
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.