Created attachment 94697 [details] the picture of the monitor Environment: ------------------- Kernel: (drm-intel-next-queued) 4c0e552882114d1edb588242d45035246ab078a0 Libdrm: (master)libdrm-2.4.52-4-gc5de5abbd90333fe1359283fb3a5e457b0f389f3 Mesa: (master)5e639a5f59a348abddff8f2cd475c00ef79c8776 Xserver: (master)xorg-server-1.15.0-631-g0f10cfd4b903d4db293ec47c8a9a0d8b33965803 Xf86_video_intel:(master)2.99.910-60-g64fc1bb9c87e95ff484ecd11f391b1c0d556d584 Cairo: (master)4144307dbfbe7b297135d9ea4b080cae7e06b997 Libva: (staging)d46a3d927ce66e0f7b61c8c184cf80b6d926327e Libva_intel_driver: (staging)bd630edd844b88ea543a027654db296ff7da16cd Platform: HSW & HSW ULT & IVB Description: ------------------------ After started X and played the video with command "mplayer -vo xv MPEG-2.mpeg", the monitor failed to play the video and only showed a black window in the middle. I took a picture and added it in the attachment. And the console will printed the error info like: "X11 error: BadAlloc (insufficient resources for operation)". The dmesg info and the Xorg.log are attached. You can check it in the attachment. This is a kernel regression. I finished the bisect and it shows: 7e0d96bc03c140cb8183955ad6f0290caa731e64 is the first bad commit commit 7e0d96bc03c140cb8183955ad6f0290caa731e64 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:26 2013 -0800 drm/i915: Use multiple VMs -- the point of no return As with processes which run on the CPU, the goal of multiple VMs is to provide process isolation. Specific to GEN, there is also the ability to map more objects per process (2GB each instead of 2Gb-2k total). For the most part, all the pipes have been laid, and all we need to do is remove asserts and actually start changing address spaces with the context switch. Since prior to this we've converted the setting of the page tables to a streamed version, this is quite easy. One important thing to point out (since it'd been hotly contested) is that with this patch, every context created will have it's own address space (provided the HW can do it). v2: Disable BDW on rebase NOTE: I tried to make this commit as small as possible. I needed one place where I could "turn everything on" and that is here. It could be split into finer commits, but I didn't really see much point. Cc: Eric Anholt <eric@anholt.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> :040000 040000 6b7ce2450cf223cc5aff29bc4eb2753df0f5680e 8c6ad9549bbee5a4cc8140235d3fa6d24aaff813 M drivers :040000 040000 5eb628d96ee3de27a90423ba826cc0d451e9a90c 667b43f6276b42af29b6176eda664a5cf3cf0f3e M include Steps: --------------------------- 1. xinit & 2. mplayer -vo xv /home/testframework/MPEG-2.mpeg
Created attachment 94698 [details] dmesg info after start x and run mplayer
Created attachment 94699 [details] Xorg log
[ 60.736334] [drm] GPU crash dump saved to /sys/class/drm/card0/error Please upload this.
Created attachment 94707 [details] error info get from /sys/class/drm/card0/error
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 10fd19f..cba420b 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1779,8 +1779,8 @@ hsw_ring_dispatch_execbuffer(struct intel_ring_buffer *ring, return ret; intel_ring_emit(ring, - MI_BATCH_BUFFER_START | MI_BATCH_PPGTT_HSW | - (flags & I915_DISPATCH_SECURE ? 0 : MI_BATCH_NON_SECURE_HSW)); + MI_BATCH_BUFFER_START | + (flags & I915_DISPATCH_SECURE ? 0 : MI_BATCH_PPGTT_HSW | MI_BATCH_NON_SECURE_HSW)); /* bit0-7 is the length on GEN6+ */ intel_ring_emit(ring, offset); intel_ring_advance(ring);
+1 for new batch buffer finder.
Created attachment 94798 [details] dmesg info of patched kernel after start x and play video After I applied the patch Chris gave in comment 5, there is no error info like: "X11 error: BadAlloc (insufficient resources for operation)" again when run the "mplayer -vo xv MPEG-2.mpeg". But the monitor still failed to play the video and only showed a black window in the middle.
Assigning to Chris to submit the patch in comment #5 (maybe that happened already, but I'm vacation-mail-recovering ...).
So the continued failure here is then likely to be that it is attempting to read the surface data from ggtt when it is only in ppgtt. We've leapt from the frying pan into the fire.
I was about to say "maybe we should give up on secure...." GIVE ME BACK PIN!
secure batches are still broken with full ppgtt, aren't they? Likely outcome for 3.15 is that full ppgtt will be disabled ... Can you please test with i915.enable_ppgtt=1
Created attachment 95134 [details] dmesg info with i915.enable_ppgtt=1 set After set the i915.enable_ppgtt=1 and test with the latest drm-intel-nightly kernel(3d805d), the "mplayer -vo xv " can play the video correctly and there is no error info again.
Yay, someone actually managed to hit the botched secure dispatch with full ppgtt. I'm impressed. Anyway the offending code is disabled and we have this on our todo, including a better testcase to catch it earlier next time around.
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.