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
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.