Created attachment 98666 [details] dmesg *System Environment: -------------------------- Regression: No. The cases always fails Non-working platforms: BYT *kernel: -------------------------- -nightly: dd28119c31cf06fc4c3bb548699018a91e45a676 (fails) -queued: 1cf0ba14740d96fbf6f58a201f000a34b74f4725 (fails) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon May 5 09:07:33 2014 +0100 drm/i915: Flush request queue when waiting for ring space During the review of commit 1f70999f9052f5a1b0ce1a55aff3808f2ec9fe42 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 27 22:43:07 2014 +0000 drm/i915: Prevent recursion by retiring requests when the ring is full Ville raised the point that our interaction with request->tail was likely to foul up other uses elsewhere (such as hang check comparing ACTHD against requests). However, we also need to restore the implicit retire requests that certain test cases depend upon (e.g. igt/gem_exec_lut_handle), this raises the spectre that the ppgtt will randomly call i915_gpu_idle() and recurse back into intel_ring_begin(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78023 Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> [danvet: Remove now unused 'tail' variable as spotted by Brad.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> -fixes: e4c610fe051579ba0a1fadf339905b0231c6ef94 (skips) Author: Egbert Eich <eich@suse.de> Date: Fri Apr 11 19:07:44 2014 +0200 drm/i915/SDVO: For sysfs link put directory and target in correct order When linking the i2c sysfs file into the connector's directory pass directory and link target in the right order. This code was introduced with: commit 931c1c26983b4f84e33b78579fc8d57e4a14c6b4 Author: Imre Deak <imre.deak@intel.com> Date: Tue Feb 11 17:12:51 2014 +0200 drm/i915: sdvo: add i2c sysfs symlink to the connector's directory This is the same what we do for DP connectors, so make things more consistent. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> *Bug detailed description: ----------------------------- Some subcases of igt/gem_exec_parse below fails igt/gem_exec_parse/basic-rejected igt/gem_exec_parse/batch-without-end igt/gem_exec_parse/bitmasks igt/gem_exec_parse/oacontrol-tracking igt/gem_exec_parse/registers Output: ./gem_exec_parse --run-subtest registers IGT-Version: 1.6-g7935bbd (x86_64) (Linux: 3.15.0-rc3_drm-intel-next-queued_1cf0ba_20140508+ x86_64) Test assertion failure function exec_batch, file gem_exec_parse.c:134: Last errno: 0, Success Failed assertion: expected_ret == 0 Subtest registers: FAIL The result on -fixes was skipped: ./gem_exec_parse --run-subtest registers IGT-Version: 1.6-g7935bbd (x86_64) (Linux: 3.15.0-rc3_drm-intel-fixes_e4c610_20140508+ x86_64) Test requirement not met in function __real_main210, file gem_exec_parse.c:222: Last errno: 22, Invalid argument Test requirement: (!(!rc && parser_version > 0)) Subtest registers: SKIP *Reproduce steps: ---------------------------- 1. ./gem_exec_parse --run-subtest registers
Created attachment 98667 [details] dmesg on fixes branch
This is known to be broken on -fixes. Please only reopen if there are failures with gem_exec_param on byt on -nightly.
Created attachment 104602 [details] dmesg (In reply to comment #2) > This is known to be broken on -fixes. Please only reopen if there are > failures with gem_exec_param on byt on -nightly. Test failed on latest -nightly(da31e7c60be217316278a055dd3f91c33913270f) on byt-m root@x-bytm02:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./gem_exec_parse IGT-Version: 1.7-geda904c (x86_64) (Linux: 3.16.0_drm-intel-nightly_da31e7_20140814+ x86_64) Subtest basic-allowed: SUCCESS Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest basic-rejected: FAIL Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest registers: FAIL Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest bitmasks: FAIL Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest batch-without-end: FAIL Subtest cmd-crossing-page: SUCCESS Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest oacontrol-tracking: FAIL
This bug is able to reproduce on IVB and HSW platforms. [root@x-ivb9 tests]# ./gem_exec_parse IGT-Version: 1.7-g5c7bcb1 (x86_64) (Linux: 3.16.0_drm-intel-nightly_da31e7_20140814_debug+ x86_64) Subtest basic-allowed: SUCCESS Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest basic-rejected: FAIL Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest registers: FAIL Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest bitmasks: FAIL Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest batch-without-end: FAIL Subtest cmd-crossing-page: SUCCESS Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 == -22 Subtest oacontrol-tracking: FAIL
It works well on -nightly kernel. It also happens on -fixes kernel(commit f114040e3ea6e0737) run ./gem_exec_parse --run-subtest registers output: IGT-Version: 1.8-gbba1cd0 (x86_64) (Linux: 3.18.0-rc1_drm-intel-fixes_f11404_20141021_debug+ x86_64) Test assertion failure function exec_batch, file gem_exec_parse.c:135: Failed assertion: __gem_execbuf(fd, &execbuf) == expected_ret error: 0 != -22 Subtest registers: FAIL (0.000s)
If it works well on -nightly it was probably fixed already. Feel free to reopen if it still happens.
pass on BYT/HSW/IVB with nightly latest baranch: d2a1764437d8b4c30948704ff6c64e4bbfd1df7c(2015-01-20) change state to verified.
Closing old verified.
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.