On 2026-08-31 at 11:33:08 +0200, Janusz Krzysztofik wrote: > CI extreamly sporadically (five times over last six mohths) reported > failures of igt@i915_selftest@live@hangcheck on ARL-S machines. The > selftest was timing out while waiting up to 1 second for a request > supposed to trigger a GPU hang to be started. It occurred possible to > reproduce this issue manually by running the selftest in a loop for a > few hours. > > Among results from 5 occurrences reported by CI so far, and two manual > reproductions, two of them contained messages that suggested a > posssibility of the awaited request to actually start soon after > timeout. With the timeout extended from 1 to 2 seconds, it occurred no > longer possible to trigger the failure, even when running the test in a > loop for 10, then for 12 hours, on the same machine where it was failing > before in 2-3 hours. > > Assume the conditions that prevented the hang requests to start within 1 > second were always transient, and 2 seconds is sufficient for those > requests to start effectively on machines in the CI environment. Fix > the issue by using that value as the timeout. >
What's the median request start time under usual conditions? It's interesting to me why a timeout of 1s doesn't capture all occurences but 2s seems to do so. If the usual start time is on the order of few hundred ms, then it's very possible maybe 90% of requests start within 1s and CI just exposes the 10% via large numbers. But if the start time is usually ~10ms or ~1ms, is there some slowpath that triggers from time to time that is expected to take on the order of ~100ms or ~1s? Or maybe a scheduling, or power issue? This patch does no harm and gets CI scripts to shut up about an otherwise working test. But there is a world where the CI fails are exposing some very subtle bug (though I sincerely doubt it's any urgent or worth going out of your way to fix) Otherwise with the Krzysztof Karas's comments about commit log: Reviewed-by: Krzysztof Niemiec <[email protected]> Thanks Krzysztof
