Bug 98981 - [IVB] igt/gem_exec_suspend/basic-s3 hangs when used with intel-ci/fast-feedback.testlist
Summary: [IVB] igt/gem_exec_suspend/basic-s3 hangs when used with intel-ci/fast-feedba...
Status: CLOSED DUPLICATE of bug 106220
Alias: None
Product: DRI
Classification: Unclassified
Component: IGT (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-03 11:35 UTC by Dorota Czaplejewicz
Modified: 2018-08-31 11:19 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Increases the delay between the suspend request and the alarm event (418 bytes, patch)
2016-12-03 13:22 UTC, Dorota Czaplejewicz
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Dorota Czaplejewicz 2016-12-03 11:35:49 UTC
The test igt/gem_exec_suspend/basic-s3 does not wake up from suspend when invoked as part of the testlis tintel-ci/fast-feedback.testlist

Manual wake up is needed, afterwards test reports pass.

I am in the process of finding the minimal test case.

So far, the smallest test set that triggers this:
sudo IGT_TEST_ROOT=`pwd`/intel-gpu-tools/tests ./piglit/piglit run igt -o results -l verbose -s --test-list intel-gpu-tools/tests/intel-ci/fast-feedback.testlist -t gem_exec

While specifying tests separately, the hangup does not occur:



Log of the complete run with a manual wakeup:
Time 	0:04:10.425812
Stdout 	

IGT-Version: 1.17-g901c2bb (x86_64) (Linux: 4.9.0-rc7-CI-CI_DRM_1849+ x86_64)
rtcwake: wakeup from "mem" using /dev/rtc0 at Sat Dec  3 11:19:08 2016
Subtest basic-S3: SUCCESS (18.487s)


System:
Fedora 24, i7-3770, ASRock H77 Pro4/MVP
Comment 1 Dorota Czaplejewicz 2016-12-03 13:22:53 UTC
Created attachment 128317 [details] [review]
Increases the delay between the suspend request and the alarm event
Comment 2 Dorota Czaplejewicz 2016-12-03 13:23:22 UTC
The problem doesn't seem to appear every time now. My suspicion is that the wakeup alarm comes before the system is fully suspended, because increasing the delay makes the issue go away completely.

I have attached a patch that bumps the interval from 15s to 20s.

Perhaps an ideal solution - without making the timeout very large - would be to set a few repeating alarms in succession when such functionality is available, and if that's not possible, to fall back on a large enough value.
Unfortunately, I didn't find any easy way to do that.
Comment 3 Chris Wilson 2016-12-03 15:40:46 UTC
One question is why is taking longer than 15s (from time of alarm setup) to suspend? That in itself a failure to meet user expectations. (But yes igt, or at least the CI test harness, needs to be robust.)
Comment 4 Dorota Czaplejewicz 2016-12-05 09:41:37 UTC
Perhaps I can time the process if you think it's relevant - currently I'm guessing the reason. Any suggestions on capturing timestamps?
Comment 5 Chris Wilson 2016-12-05 10:00:35 UTC
Something like initcall_debug should show the times during suspend as well. Otherwise it will be a chore of adding printk to ensure we have timing events along the relevant callchains.
Comment 6 Elizabeth 2017-10-16 16:57:16 UTC
Hello everybody,
Any update at this? According to https://intel-gfx-ci.01.org/tree/drm-tip/fi-ivb-3520m.html and https://intel-gfx-ci.01.org/tree/drm-tip/fi-ivb-3770.html the test igt@gem_exec_suspend@basic-s3 haven't failed recently.
Comment 7 Lakshmi 2018-08-31 11:19:18 UTC
This bug is outdated. Replace with the one used in CIbuglog.

*** This bug has been marked as a duplicate of bug 106220 ***


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.