Bug 98981

Summary: [IVB] igt/gem_exec_suspend/basic-s3 hangs when used with intel-ci/fast-feedback.testlist
Product: DRI Reporter: Dorota Czaplejewicz <dorota.czaplejewicz>
Component: IGTAssignee: Default DRI bug account <dri-devel>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: medium CC: dorota.czaplejewicz, l094043
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Increases the delay between the suspend request and the alarm event none

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.