Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
The migration is almost done, at least the rest should happen in the background. There are still a few technical difference between the old cluster and the new ones, and they are summarized in this issue. Please pay attention to the TL:DR at the end of the comment.
Project 'drm/intel' was moved to 'drm/i915/kernel'. Please update any links and bookmarks that may still have the old path.
[soraka] igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: did not conserve power when setting lower frequency!, i915/intel_gt_pm_live_selftests: live_rps_power failed with error -22
As far as I can tell, this is specific to the kbl-soraka chromebook. The theory is that the BIOS has restricted the GPU to minimum frequencies. Needless to say this will be dramatically impacting upon test runtimes.
Chris Wilsonchanged title from igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: did not conserve power when setting lower frequency!, i915/intel_gt_pm_live_selftests: live_rps_power failed with error -22 to [soraka] igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: did not conserve power when setting lower frequency!, i915/intel_gt_pm_live_selftests: live_rps_power failed with error -22
changed title from igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: did not conserve power when setting lower frequency!, i915/intel_gt_pm_live_selftests: live_rps_power failed with error -22 to [soraka] igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: did not conserve power when setting lower frequency!, i915/intel_gt_pm_live_selftests: live_rps_power failed with error -22
The CI Bug Log issue associated to this bug has been updated by Lakshmi Vudum.
New filters associated
KBL: igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: did not conserve power when setting lower frequency!, i915/intel_gt_pm_live_selftests: live_rps_power failed with error -22
The CI Bug Log issue associated to this bug has been updated by Lakshmi Vudum.
New filters associated
TGL KBL: igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: could not set minimum frequency, i915/intel_gt_pm_live_selftests: live_rps_control failed with error -22
(No new failures associated)
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description:TGL KBL TGL: igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: could not set minimum frequency, i915/intel_gt_pm_live_selftests: live_rps_control failed with error -22
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND (machine_name IS IN ["fi-kbl-soraka", "shard-kbl3", "shard-kbl5", "shard-kbl4", "shard-kbl7", "fi-tgl-u", "re-tgl-u", "fi-tgl-u2", "shard-tglb1", "shard-tglb2", "shard-tglb3", "shard-tglb4", "shard-tglb5", "shard-tglb6", "fi-kbl-7500u", "re-tgl1-display", "re-tgl2-display", "shard-kbl6", "shard-tglb7", "shard-tglb8", "shard-kbl1", "fi-kbl-7560u", "fi-tgl-y", "re-tgl-y", "shard-tglb0", "shard-tglb9", "re-tgl-cham", "fi-kbl-7567u", "fi-tgl-guc", "fi-kbl-r", "re-tgl-u2", "fi-tgl-dsi", "shard-kbl2", "ba-tgl-1", "custom-tgl-joshikun", "shard-kbl", "fi-kbl-guc", "fi-kbl-x1275", "fi-kbl-8809g"] OR machine_tag IS IN ["KBL", "TGL"]) AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@i915_selftest@live@gt_pm"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["dmesg-fail"])) AND dmesg ~= 'rcs0: could not set minimum frequency.*\n.*i915/intel_gt_pm_live_selftests: live_rps_control failed with error -22'
<3> [627.612671] rcs0: could not set minimum frequency [6], only 18!<3> [627.625389] i915/intel_gt_pm_live_selftests: live_rps_control failed with error -22
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description:KBLGEN9: igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: did not conserve power when setting lower frequency!, i915/intel_gt_pm_live_selftests: live_rps_power failed with error -22
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND (machine_name IS IN ["shard-kbl3", "fi-glk-1", "shard-glkb1", "shard-glkb3", "shard-apl6", "fi-skl-6770hq", "fi-skl-6260u", "shard-apl2", "shard-kbl5", "fi-bxt-j4205", "shard-kbl4", "shard-glkb6", "shard-glkb2", "shard-kbl7", "fi-skl-6700hq", "fi-skl-6600u", "shard-apl5", "shard-apl7", "fi-bxt-dsi", "shard-glkb4", "shard-apl8", "shard-apl1", "fi-glk-dsi", "fi-kbl-7500u", "shard-kbl6", "shard-apl4", "shard-glkb5", "shard-kbl1", "fi-kbl-7560u", "shard-apl3", "fi-skl-6700k2", "fi-kbl-r", "fi-kbl-7567u", "fi-cfl-s2", "fi-skl-gvtdvm", "shard-kbl2", "fi-skl-guc", "fi-cfl-8700k", "fi-cfl-u", "fi-cfl-s3", "fi-glk-j4005", "shard-apl", "shard-glk", "shard-kbl", "shard-glk1", "shard-glk3", "shard-glk4", "shard-glk5", "shard-glk2", "shard-glkb", "shard-glk8", "shard-glk6", "shard-glk7", "pig-skl-6600", "pig-glk-j4005", "pig-glk-j5005", "fi-cfl-guc", "fi-kbl-guc", "fi-cfl-u2", "pig-skl-6260u", "fi-whl-u", "fi-kbl-x1275", "shard-glk9", "fi-cfl-8109u", "fi-skl-iommu", "fi-kbl-8809g", "fi-skl-caroline", "fi-apl-nasher", "fi-kbl-soraka", "shard-skl", "shard-skl1", "shard-skl2", "shard-skl3", "shard-skl4", "shard-skl5", "shard-skl6", "shard-skl7", "shard-skl8", "shard-skl9", "shard-skl10", "fi-apl-guc", "fi-skl-lmem", "fi-cml-u", "re-cml-u", "fi-cml-u2", "fi-cml-h", "fi-cml-s", "shard-apl0", "shard-glk0", "shard-kbl0", "shard-skl0"] OR machine_tag IS IN ["KBLGEN9"]) AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@i915_selftest@live@gt_pm"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["dmesg-fail"])) AND stderr ~= 'rcs0: did not conserve power when setting lower frequency!\n.*i915/intel_gt_pm_live_selftests: live_rps_power failed with error -22'
The failure report of not having lower power usage at lower frequency is firing because the min and max frequencies being compared are actually ~the same due to frequency clipping issues as tracked in #413 (closed)
Let's not confuse the Tigerlake report here, since that is a whole different kettle of fish and at least B0 is responding to RPS controls unlike the A0 being tested in BAT.
We have two machines which are throttled to min GPU clocks and with which we can do nothing useful. This is now reported before we get to noticing that we can't conserve power.
The failure report of not having lower power usage at lower frequency may be firing because the min and max frequencies being compared are actually ~the same due to frequency clipping issues as tracked in #413 (closed). Although this is happening on older platforms. The requested frequencies are being tested for being achieved before the power measurements are done, so maybe they are then throttled immediately.
Setting severity as major to match #413 (closed). Priority to high as impact to TGL not clear, given ongoing work for #413 (closed) .
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description: KBL TGL: igt@i915_selftest@live@gt_pm - dmesg-fail - rcs0: could not set minimum frequency, i915/intel_gt_pm_live_selftests: live_rps_control failed with error -22
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND (machine_name IS IN ["fi-kbl-7567u", "fi-kbl-soraka", "shard-kbl3", "shard-kbl2", "fi-kbl-guc", "fi-kbl-7500u", "shard-kbl5", "shard-kbl6", "fi-kbl-x1275", "shard-kbl4", "shard-kbl", "fi-kbl-8809g", "shard-kbl1", "fi-kbl-7560u", "shard-kbl7", "fi-kbl-r"] OR machine_tag IS IN ["KBL", "TGL"]) AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@i915_selftest@live@gt_pm"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["dmesg-fail"])) AND dmesg ~= 'rcs0: could not set minimum frequency.*\n.*i915/intel_gt_pm_live_selftests: live_rps_control failed with error -22'