Last seen:  CI_DRM_3333: 2017-11-11 / 237 runs ago, it's time to close and archive.

Seen again: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3625/shard-kbl5/igt@perf@rc6-disable.html

Right, it seems RC6 events aren't happening with 1s after we've released the i915 perf stream. Not too sure how to test that we've reenabled RC6 in a reliable fashion...

Any suggestion?

(In reply to Lionel Landwerlin from comment #3)
> Right, it seems RC6 events aren't happening with 1s after we've released the
> i915 perf stream. Not too sure how to test that we've reenabled RC6 in a
> reliable fashion...
> 
> Any suggestion?

debugfs/i915_drpc_info (Deep-, Deepest-) "RC6 Enabled"?

Oh, thanks for that.

Here it is when the perf stream is closed :

Deep RC6 Enabled: no
Deepest RC6 Enabled: no
Current RC state: RC6
Core Power Down: no
Render Power Well: Down
Media Power Well: Down

And opened :

Deep RC6 Enabled: no
Deepest RC6 Enabled: no
Current RC state: on
Core Power Down: no
Render Power Well: Up
Media Power Well: Up

Is the "Current RC state" the best field to tell me?

Right now we use "RC6 residency since boot" and try to verify that the number increments again when we release the perf stream.

Here is one from running shards testlist on BAT machines:

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1/fi-skl-gvtdvm/igt@perf@rc6-disable.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_30/fi-kbl-7560u/igt@perf@rc6-disable.html

(perf:1658) CRITICAL: Test assertion failure function test_rc6_disable, file ../tests/perf.c:3633:
(perf:1658) CRITICAL: Failed assertion: n_events_end - n_events_start != 0
(perf:1658) CRITICAL: Last errno: 9, Bad file descriptor
(perf:1658) CRITICAL: error: 0 == 0
Subtest rc6-disable failed.

Lionel, any updates on this issue?

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_130/fi-skl-6700hq/igt@perf@rc6-disable.html

Starting subtest: rc6-disable
(perf:1541) CRITICAL: Test assertion failure function test_rc6_disable, file ../tests/perf.c:3649:
(perf:1541) CRITICAL: Failed assertion: n_events_end - n_events_start != 0
(perf:1541) CRITICAL: error: 0 == 0
Subtest rc6-disable failed.

Should be fixed by
https://patchwork.freedesktop.org/patch/299891/?series=59582&rev=2

(In reply to Imre Deak from comment #11)
> Should be fixed by
> https://patchwork.freedesktop.org/patch/299891/?series=59582&rev=2

Marking fixed accordingly.

Still going on:

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_351/fi-kbl-8809g/igt@perf@rc6-disable.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_351/fi-skl-gvtdvm/igt@perf@rc6-disable.html

Starting subtest: rc6-disable
(perf:1038) CRITICAL: Test assertion failure function test_rc6_disable, file ../tests/perf.c:3612:
(perf:1038) CRITICAL: Failed assertion: n_events_end - n_events_start != 0
(perf:1038) CRITICAL: error: 0 == 0

Created attachment 145189 [details]
attachment-16515-0.html

I am OOO 8/27 through 8/30.

rc6 residency is a value read from sysfs that increments when system is allowed to enter/exit rc6 states. i915 perf open gets the runtime pm so that rc6 is disabled as long as perf use case is running. perf close puts/releases the runtime pm.  The tests measures the rc6 residency around a sleep of 500 ms after calling perf_open and expects the rc6 residency value to stay the same. Later it measures the rc6 residency after calling perf close. the test expects the value to change/increment aroung the sleep. This failure is for the latter rc6 measurement when the values did not increment.

One possible reason is explained in the fix here - https://patchwork.freedesktop.org/patch/299891/?series=59582&rev=2

Machines: skl, kbl
Repro rate: 12%

Impact: Delay/Failure in rc6 residency may affect power metrics, however the prior analysis points to updating the test code to synchronize with the completion of delayed work that i915 is doing. This makes Severity - Low/Medium. Priority stays High.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/50.