Bug 94741 - piglit fails to determine deadlock happened during i-g-t test
Summary: piglit fails to determine deadlock happened during i-g-t test
Alias: None
Product: piglit
Classification: Unclassified
Component: tests (show other bugs)
Version: unspecified
Hardware: All All
: medium major
Assignee: Dylan Baker
QA Contact: Piglit Mailing List
Depends on:
Reported: 2016-03-29 13:08 UTC by Marius Vlad
Modified: 2016-03-31 12:24 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

dmesg during piglit run (59.28 KB, text/plain)
2016-03-29 13:49 UTC, Marius Vlad
Results json (12.79 KB, text/plain)
2016-03-29 16:50 UTC, Marius Vlad
dmesg before (44.58 KB, text/plain)
2016-03-29 16:51 UTC, Marius Vlad
HTML results (16.79 KB, text/plain)
2016-03-29 16:51 UTC, Marius Vlad

Description Marius Vlad 2016-03-29 13:08:53 UTC
Seems that piglit fails to determine that during a test the kernel spew a 
deadlock warning trace in dmesg:


This might be related to the fact that the warning is generated right after
exiting suspend.
Comment 1 Marius Vlad 2016-03-29 13:49:45 UTC
Created attachment 122611 [details]
dmesg during piglit run

Attached dmesg during piglit run.
Comment 2 Dylan Baker 2016-03-29 16:28:40 UTC
Please also upload the piglit results, I have an idea what may be happening, but I'll need the results to confirm them.
Comment 3 Marius Vlad 2016-03-29 16:50:50 UTC
Created attachment 122615 [details]
Results json
Comment 4 Marius Vlad 2016-03-29 16:51:08 UTC
Created attachment 122616 [details]
dmesg before
Comment 5 Marius Vlad 2016-03-29 16:51:43 UTC
Created attachment 122617 [details]
HTML results
Comment 6 Marius Vlad 2016-03-29 16:54:12 UTC
One of my colleagues noticed that the test is skipped -- which is what might happen here. What confused me is that the test exits with 0 instead of 77 (default return when that happens).

Most likely this is a issue with i-g-t which we have a patch for, but if you don't mind I'd like to be sure :-).
Comment 7 Marius Vlad 2016-03-29 16:55:24 UTC
PS: The html results are tarballs bzipped.
Comment 8 Gabriel Feceoru 2016-03-30 08:31:20 UTC
This specific test has a design issue which makes it doing some operations (suspend) before taking the decision to be skipped. The dmesg trace  is caused by resume part.

Now, about piglit, should it mark the test as dmesg-warn, although it was skipped?
Comment 9 Dylan Baker 2016-03-30 17:50:24 UTC
It's doing exactly what it's intended to do when it doesn't change the result to dmesg-*. Basically what happens is after the test runs and it does it's own test specific result handling (the interpret_result method) it gets passed to the Dmesg class which will change pass to dmesg-warn, and warn and fail to dmesg-fail. You can look at the code in dmesg.py (BaseDmesg.update_result). So skip shouldn't be converted, piglit assumes that the test code knows what it's doing when it sets the status to skip.

I think that we've resolved this isn't a piglit bug, it's an IGT bug. So I'm going to mark this resolved as 'notourbug', but please reopen if that's not correct.
Comment 10 Gabriel Feceoru 2016-03-31 06:59:06 UTC
Agree with Dylan, not a piglit bug.
Comment 11 Marius Vlad 2016-03-31 12:24:11 UTC
Thanks for clarifying.

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.