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
Created attachment 122611 [details]
dmesg during piglit run
Attached dmesg during piglit run.
Please also upload the piglit results, I have an idea what may be happening, but I'll need the results to confirm them.
Created attachment 122615 [details]
Created attachment 122616 [details]
Created attachment 122617 [details]
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 :-).
PS: The html results are tarballs bzipped.
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?
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.
Agree with Dylan, not a piglit bug.
Thanks for clarifying.