https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1/fi-byt-j1900/igt@gem_exec_big.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1/fi-bsw-n3050/igt@gem_exec_big.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1/fi-byt-n2820/igt@gem_exec_big.html [95/97] skip: 63, pass: 32 - running: igt/gem_exec_big [95/97] skip: 63, pass: 32 \ owatch: TIMEOUT!
Let it run to completion and then tell me if there's a bug. Doing a few million execbufs with ranges from 4KiB to 4GiB touching all pages does take some time.
Imo, this is a bug in CI for using owatch.
(In reply to Chris Wilson from comment #2) > Imo, this is a bug in CI for using owatch. We have to limit the runtime if your test can't make it in the timing budget they belong to the blacklist
(In reply to Marta Löfstedt from comment #3) > (In reply to Chris Wilson from comment #2) > > Imo, this is a bug in CI for using owatch. > > We have to limit the runtime if your test can't make it in the timing budget > they belong to the blacklist That is not a bug in the test or kernel though. That is a limitation imposed by CI and needs to be reported as such, or rather handled entirely by CI since that wants to redefine tests to suite itself rather than the intent of the test. In this case owatch is entirely the wrong tool; nothing is expected to be on the output yet the test is still running perfectly fine. As a watchdog, owatch fails for this test.
(In reply to Chris Wilson from comment #4) > (In reply to Marta Löfstedt from comment #3) > > (In reply to Chris Wilson from comment #2) > > > Imo, this is a bug in CI for using owatch. > > > > We have to limit the runtime if your test can't make it in the timing budget > > they belong to the blacklist > > That is not a bug in the test or kernel though. That is a limitation imposed > by CI and needs to be reported as such, or rather handled entirely by CI > since that wants to redefine tests to suite itself rather than the intent of > the test. > > In this case owatch is entirely the wrong tool; nothing is expected to be on > the output yet the test is still running perfectly fine. As a watchdog, > owatch fails for this test. Feedback to owatch would have come if the test had finished within the time-buget which in this case is 410 seconds.
Possibly related to bug 107937 ?
This is not a bug, but a test case that takes a long time to run as it really does want to exercise every page in a very, very large batch buffer. You may want to replace the test with another that only looks at some combinations of pages + total size, that would be a different non-exhaustive test.
*** Bug 107937 has been marked as a duplicate of this bug. ***
*** Bug 107775 has been marked as a duplicate of this bug. ***
Let's join the conversation in #107936 *** This bug has been marked as a duplicate of bug 107936 ***
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.