Created attachment 96437 [details] dmesg System Environment: -------------------------- Platform: Ivybridge Kernel: drm-intel-nightly/07071a9d41aed59f4f2ba66afb82ec35557a80c1 Bug detailed description: ----------------------------- It fails on Ivybridge and haswell with -queued and -nightly kernel. Bisect shows: 6d42f94084b8c69813d7ecd0466c33fe561bf127 is the first bad commit commit 6d42f94084b8c69813d7ecd0466c33fe561bf127 Author: Brad Volkin <bradley.d.volkin@intel.com> AuthorDate: Tue Feb 18 10:15:57 2014 -0800 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Tue Mar 25 14:11:39 2014 +0100 drm/i915: Enable command parsing by default v2: rebased OTC-Tracker: AXIA-4631 Change-Id: I6747457e1fe7494bd42787af51198fcba398ad78 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Resolve tiny conflict in module option text.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> output: IGT-Version: 1.6-gc819014 (x86_64) (Linux: 3.14.0-rc7_drm-intel-nightly_07071a_20140326+ x86_64) Test assertion failure function gem_execbuf, file ioctl_wrappers.c:396: Last errno: 22, Invalid argument Failed assertion: ret == 0 Reproduce steps: ---------------------------- 1. ./gen7_forcewake_mt
Run the test case as root... if only.
FORCEWAKE_MT should be fully allowed, if you're master ... is the test failing to acquire that? At least we should have a little check in there whether we are actually master and fail a bit earlier.
The test is to make sure I could actually write the suggested workaround for making sure that multiple display writes do not land simultaneous - that is it also does a STORE_REGISTER_MEM - as some versions of the ddx has done as well.
And yes it takes advantage of certain dispatch infrastructure to assume that it has a ggtt offset to use.
*** Bug 77849 has been marked as a duplicate of this bug. ***
Created attachment 98634 [details] [review] Patch to modify the test
Please test with the attached patch (0001-tests-gen7_forcewake_mt-Don-t-set-the-GGTT-bit-in-SR.patch). It modifies the test to not violate the command parser's rules. There is an open discussion about whether this is the correct approach or not, but I believe it is.
(In reply to comment #6) > Created attachment 98634 [details] [review] [review] > Patch to modify the test Fixed by this patch.
commit 0fee90b56df9a644b305f6cf37785b8284d410b3 Author: Brad Volkin <bradley.d.volkin@intel.com> Date: Sat May 10 14:11:53 2014 -0700 tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command The command parser in newer kernels will reject it and setting this bit is not required for the actual test case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Verified.Fixed.
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.