Created attachment 101999 [details] dmesg ==System Environment== -------------------------- Regression: No. It's first time to run the test. Non-working platforms: BYT ==kernel== -------------------------- origin/drm-intel-nightly: 1087d4bf01e79523898c6c31615bf0c369e0039a(fails) drm-intel-nightly: 2014y-06m-25d-13h-11m-05s integration manifest origin/drm-intel-next-queued: 91565c85b66db820f01894a971d39aaef60c4325(fails) drm/i915: Don't try to look up object for non-existent fb origin/drm-intel-fixes: 8525a235c96a548873c6c5644f50df32b31f04c6(fails) drm/i915: vlv_prepare_pll is only needed in case of non DSI interfaces ==Bug detailed description== igt/pm_rps subcases fail Output: [root@x-bsw01 tests]# ./pm_rps IGT-Version: 1.7-g67e29a3 (x86_64) (Linux: 3.16.0-rc2_kcloud_1305a9_20140630+ x86_64) Test assertion failure function __real_main545, file pm_rps.c:567: Last errno: 0, Success Failed assertion: val >= 0 Subtest basic-api: FAIL Subtest min-max-config-idle: FAIL Subtest min-max-config-loaded: FAIL Subtest reset: FAIL Subtest blocking: FAIL ==Reproduce steps== ---------------------------- 1. ./pm_rps
for CHV We don't have the conversion from encode to Freq
Update Non-working platforms: BSW
*** Bug 80884 has been marked as a duplicate of this bug. ***
The failure still able to reproduce on latest -nightly(7101d84020f63f1da7e0c5d021cdd6be4d515de5) [root@x-bsw01 tests]# ./pm_rps --run-subtest basic-api IGT-Version: 1.8-g4b81e9c (x86_64) (Linux: 3.17.0-rc6_drm-intel-nightly_7101d8_20140926+ x86_64) Test assertion failure function do_writeval, file pm_rps.c:105: Failed assertion: readval(filp) == val Subtest basic-api: FAIL (0.004s) [root@x-bsw01 tests]# ./pm_rps --run-subtest reset IGT-Version: 1.8-g4b81e9c (x86_64) (Linux: 3.17.0-rc6_drm-intel-nightly_7101d8_20140926+ x86_64) Test assertion failure function loaded_check, file pm_rps.c:430: Failed assertion: freqs[CUR] == freqs[MAX] error: 416 != 624 Subtest reset: FAIL (48.441s) Test assertion failure function load_helper_stop, file pm_rps.c:253: Failed assertion: igt_wait_helper(&lh.igt_proc) == 0 Last errno: 10, No child processes pm_rps: igt_core.c:782: igt_fail: Assertion `!test_with_subtests || in_fixture' failed. Aborted (core dumped)
Please retest with current drm-intel-nightly.
This issue still exist. ./pm_rps IGT-Version: 1.9-gebd8b32 (x86_64) (Linux: 3.19.0-rc6_drm-intel-nightly_70438b_20150128+ x86_64) Subtest basic-api: SUCCESS (0.008s) Subtest min-max-config-idle: SUCCESS (3.374s) Subtest min-max-config-loaded: SUCCESS (14.005s) (pm_rps:4273) intel-batchbuffer-CRITICAL: Test assertion failure function intel_batchbuffer_flush_on_ring, file intel_batchbuffer.c:180: (pm_rps:4273) intel-batchbuffer-CRITICAL: Failed assertion: (drm_intel_gem_bo_context_exec(batch->bo, ctx, used, ring)) == 0 (pm_rps:4273) intel-batchbuffer-CRITICAL: Last errno: 16, Device or resource busy Subtest reset: FAIL (84.933s) (pm_rps:4266) CRITICAL: Test assertion failure function loaded_check, file pm_rps.c:509: (pm_rps:4266) CRITICAL: Failed assertion: freqs[CUR] == freqs[MAX] (pm_rps:4266) CRITICAL: error: 200 != 640 Subtest reset: FAIL (87.948s) (pm_rps:4266) CRITICAL: Test assertion failure function readval, file pm_rps.c:78: (pm_rps:4266) CRITICAL: Failed assertion: scanned == 1 Subtest blocking: FAIL (10.809s) (pm_rps:4266) CRITICAL: Test assertion failure function load_helper_stop, file pm_rps.c:290: (pm_rps:4266) CRITICAL: Failed assertion: igt_wait_helper(&lh.igt_proc) == 0 (pm_rps:4266) CRITICAL: Last errno: 10, No child processes pm_rps: igt_core.c:889: igt_fail: Assertion `!test_with_subtests || in_fixture' failed. Aborted (core dumped)
still happen on SKL-Y with the latest kernel : Kernel commit log: commit b4c4542ba1abfb0d3d6913504502573bf2c62b12 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 28 15:51:30 2015 +0200 drm-intel-nightly: 2015y-08m-28d-13h-50m-34s UTC integration manifest only this two test cases passed : pm_rps@basic-api pm_rps@min-max-config-idle
Same Behavior with BDW-U with following configuration Kernel 4.3.0-rc8-drm-intel-testing-2015-08-28 Mesa: mesa-10.6.7 from http://cgit.freedesktop.org/mesa/mesa/ Xf86_video_intel: 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ Libdrm: libdrm-2.4.64 from http://cgit.freedesktop.org/mesa/drm/ Cairo: 1.14.2 from http://cgit.freedesktop.org/cairo libva: libva-1.6.0 from http://cgit.freedesktop.org/libva/ intel-driver: 1.6.1. from http://cgit.freedesktop.org/vaapi/intel-driver xorg: 1.17.99 installed with script git_xorg.sh Xserver: xorg-server-1.17.2 from http://cgit.freedesktop.org/xorg/xserver Intel-gpu-tools: 1.12 from http://cgit.freedesktop.org/xorg/app/intel-gpu Subtests failing: m_rps@basic-api igt@pm_rps@blocking igt@pm_rps@reset igt@pm_sseu@full-enable
Got same issue on Haswell-U, as well latest configuration Kernel 4.3.0-rc8-drm-intel-testing-2015-08-28 Mesa: mesa-10.6.7 from http://cgit.freedesktop.org/mesa/mesa/ Xf86_video_intel: 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ Libdrm: libdrm-2.4.64 from http://cgit.freedesktop.org/mesa/drm/ Cairo: 1.14.2 from http://cgit.freedesktop.org/cairo libva: libva-1.6.0 from http://cgit.freedesktop.org/libva/ intel-driver: 1.6.1. from http://cgit.freedesktop.org/vaapi/intel-driver xorg: 1.17.99 installed with script git_xorg.sh Xserver: xorg-server-1.17.2 from http://cgit.freedesktop.org/xorg/xserver Intel-gpu-tools: 1.12 from http://cgit.freedesktop.org/xorg/app/intel-gpu Subtests failing: igt@pm_rps@blocking igt@pm_rps@reset
gt@pm_sseu@full-enable is failing with latest configuration: Kernel: http://vanaheimr.fr.intel.com/shared/out/kernels/drm-intel/WW42.1_4.3.0-rc4_c38f2c2/ xorg-server-1.17.2 libdrm-2.4.65 xf86-video-intel2.99.917 mesa-11.0.2 libva-1.6.1 intel-driver 1.6.1 cairo 1.14.2 intel-gpu-tools-1.12
Is this still and issue?
Looking at results from IGT ALL on BSW and HSW the test are now passing ww06 as an example on BSW igt all drm-intel-qa 4.10.0-rc7 d21a5cf Closing bug
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.