Created attachment 123667 [details] APL_dmesg_gem_exec_flush-basic-uc-r Platform: Broxton P A0 Platform CPU Name : Intel(R) @ 1.2 GHz (family: 6, model: 92, stepping: 8) – 4 cores SoC : BROXTON-P A0 QDF : QYE2 CRB : Apollo Lake RVPC1 Fab1 Software Bios: APLKRVPA.X64.0116.R20.1512211905 KSC: 1.05 Linux distribution: Ubuntu 15.10 64 bits Kernel: drm-intel-nightly 4.6.0-rc7 576b6d9 from http://cgit.freedesktop.org/drm-intel/ commit 576b6d9ea579527b8d6cf23f2a77ab8915465ba3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed May 11 19:11:23 2016 +0200 drm-intel-nightly: 2016y-05m-11d-17h-10m-57s UTC integration manifest libdrm-2.4.68 fc09c5a from git://anongit.freedesktop.org/mesa/drm mesa: mesa-11.1.2 7bcd827 from git://anongit.freedesktop.org/mesa/mesa cairo: 1.15.2 db8a7f1 from git://anongit.freedesktop.org/cairo xorg-server-1.18.0 7f04946 from git://git.freedesktop.org/git/xorg/xserver xf86-video-intel 2.99.917-645 88733a7 from git://anongit.freedesktop.org/xorg/driver/xf86-video-intel libva-1.7.0-2 4cb6d78 from git://git.freedesktop.org/git/vaapi/libva vaapi-intel-driver 1.7.0-12 4643f94 from git://anongit.freedesktop.org/vaapi/intel-driver DMC 1.07 Regression: ------------ Tested for the first time Steps: ------- 1. Execute commands: cd <...>/intel-gpu-tools/tests ./gem_exec_flush --run-subtest basic-uc-ro-before-default ./gem_exec_flush --run-subtest basic-uc-rw-before-default Actual result: --------------- Tests are fail Expected result: ----------------- Tests are Pass
Created attachment 123668 [details] APL_output_gem_exec_flush-basic-uc-r
Can you please attach the output of a full ./gem_exec_flush run (i.e. all subtests together)? The key question here is to try and decypher what flush is being missed.
The following tests cases fail under the following configuration on BXT-P tests cases ================================================================ igt@gem_exec_flush@uc-ro-before-bsd igt@gem_exec_flush@uc-ro-before-render igt@gem_exec_flush@uc-rw-before-render igt@gem_exec_flush@basic-uc-rw-before-default igt@gem_exec_flush@uc-ro-before-vebox igt@gem_exec_flush@uc-ro-before-blt igt@gem_exec_flush@uc-rw-before-blt igt@gem_exec_flush@uc-rw-before-render-interruptible igt@gem_exec_flush@uc-rw-before-bsd Hardware configuration ================================================================ Platform BXT - P (APL) Motherboard model Apollo Lake Motherboard type NOTEBOOK Hand Held Motherboard manufacturer Intel Corp. CPU family Other CPU information 06/5c GPU Card Intel Corporation Device 5a84 (rev 03) (prog-if 00 [VGA controller]) Memory ram 8 GB gfx user space ================================================================ --> Component : drm url : http://cgit.freedesktop.org/mesa/drm tag : libdrm-2.4.68 commit : fc09c5a author : Kenneth Graunke <kenneth@whitecape.org> age : 2 weeks ago --> Component : mesa url : http://cgit.freedesktop.org/mesa/mesa tag : mesa-11.1.2 commit : 7bcd827 author : Emil Velikov <emil.velikov@collabora.com> age : 3 months ago --> Component : xf86-video-intel url : http://cgit.freedesktop.org/xorg/driver/xf86-video-intel tag : 2.99.917-645-g88733a7 commit : 88733a7 author : Chris Wilson <chris@chris-wilson.co.uk> age : 7 days ago --> Component : libva url : http://cgit.freedesktop.org/libva/ tag : libva-1.7.0-2-g4cb6d78 commit : 4cb6d78 author : Alan Coopersmith <alan.coopersmith@oracle.com> age : 5 weeks ago --> Component : vaapi (intel-driver) url : http://cgit.freedesktop.org/vaapi/intel-driver tag : 1.7.0-12-g4643f94 commit : 4643f94 author : peng.chen <peng.c.chen@intel.com> age : 3 weeks ago --> Component : cairo url : http://cgit.freedesktop.org/cairo tag : 1.15.2 commit : db8a7f1 author : Bryce Harrington <bryce@osg.samsung.com> age : 5 months ago --> Component : xserver url : http://cgit.freedesktop.org/xorg/xserver tag : xorg-server-1.18.0-317-g7f04946 commit : 7f04946 author : Dave Airlie <airlied@redhat.com> age : 9 days ago --> Component : intel-gpu-tools url : http://cgit.freedesktop.org/xorg/app/intel-gpu-tools tag : intel-gpu-tools-1.14-212-g1e9a3ac commit : 1e9a3ac author : Chris Wilson <chris@chris-wilson.co.uk> age : 3 weeks ago kernel ===================================================================== commit c5034bf7729a728065a996f8042626f23074d575 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue May 17 22:50:02 2016 +0200 drm-intel-nightly: 2016y-05m-17d-20h-49m-27s UTC integration manifest Kernel version : 4.6.0 Architecture : source amd64 all Homepage : http://www.kernel.org/
Created attachment 123899 [details] apl-output-gem_exec_flush
Ok, so the extended soak tests only show the issue in the uc-before testcases. The theory here is that the CPU is doing speculative prefetches from before the call to execbuf/sync. (Or at least that is what this test was intended to detect, and since none of the others fail, it seems reasonable to assume it is this effect.) So looks like nothing to see here, an expected failure.
I need to track the basic case separately as this is not the same priority, I reported bug 95488 for the other subcases. Thanks for the explanation. Does it mean the tests should skip?
commit a1b0ed1dc48ea209b2a3a07a2d24245ad2cd1948 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 19 11:35:14 2016 +0100 igt/gem_exec_flush: Exclude -before- subtests from BAT The *-before-* tests were designed to detect a potential issue with long speculative prefetches that would load the map[] before we have even called execbuf(). As CPUs get smarter and able to look ahead further we are starting to see failures and as we know the code is deliberately buggy exclude the tests from BAT. (I want to keep the tests in the full suite so that we can record which processors are affected, and look for related issues.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95378 References: https://bugs.freedesktop.org/show_bug.cgi?id=95488 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> NOTABUG for BAT removal? Seems appropriate.
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.