Created attachment 118041 [details] dmesg (2015y-09m-01d-10h-47m-22s), 4200U started with drm.debug=7 Getting said failure since a few days on 4200U and 4770, currently on drm-intel-nightly: 2015y-09m-01d-10h-47m-22s. mesa, libdrm etc. are git versions from today as well. Basically any program (other than the first after boot, which always seems to succeed) trying to use certain hardware acceleration has a high chance of failing. It isn't consistent though, sometimes the programs run in later tries just to fail again in yet further ones afterwards. Specifically, I've seen it happen with Chrome, Steam and every mesa-demo I've tried. grepping the attacked dmesg for i915 yields in repetition: [drm:i915_gem_open] [drm:i915_gem_context_create_ioctl] HW context 1 created [drm:i915_parse_cmds] CMD: Command length exceeds batch length: 0x092C51B8 length=58 batchlen=22 [drm:i915_parse_cmds] CMD: batch set OACONTROL but did not clear it
Can you attach the output of INTEL_DEBUG=batch glxgears (which presumably also fails)?
On 4770, mesa f30cf32: intel_extensions.c:155: Batchbuffer flush with 92b (pkt) + 0b (state) = 92b (0.3%) 0x00000000: HEAD 0x69040000: 3DSTATE_PIPELINE_SELECT 0x00000004: 0x61020000: STATE_SIP 0x00000008: 0x00000000: dword 1 0x0000000c: 0x680b0001: 3DSTATE_VF_STATISTICS 0x00000010: 0x11000001: MI_LOAD_REGISTER_IMM 0x00000014: 0x00002360: dword 1 0x00000018: 0x31337000: dword 2 0x0000001c: 0x7a000003: PIPE_CONTROL 0x00000020: 0x00101c11: no write, cs stall, render target cache flush, instruction cache invalidate, texture cache invalidate, vf fetch invalidate, depth cache flush, 0x00000024: 0x00000000: destination address 0x00000028: 0x00000000: immediate dword low 0x0000002c: 0x00000000: immediate dword high 0x00000030: 0x12000001: MI_STORE_REGISTER_MEM 0x00000034: 0x00002360: dword 1 0x00000038: 0x11d2a1b8: dword 2 0x0000003c: 0x7a000003: PIPE_CONTROL 0x00000040: 0x00101c11: no write, cs stall, render target cache flush, instruction cache invalidate, texture cache invalidate, vf fetch invalidate, depth cache flush, 0x00000044: 0x00000000: destination address 0x00000048: 0x00000000: immediate dword low 0x0000004c: 0x00000000: immediate dword high 0x00000050: 0x11000001: MI_LOAD_REGISTER_IMM 0x00000054: 0x00002360: dword 1 0x00000058: 0x00000000: dword 2 0x0000005c: 0x7a000003: PIPE_CONTROL 0x00000060: 0x00101c11: no write, cs stall, render target cache flush, instruction cache invalidate, texture cache invalidate, vf fetch invalidate, depth cache flush, 0x00000064: 0x00000000: destination address 0x00000068: 0x00000000: immediate dword low 0x0000006c: 0x00000000: immediate dword high 0x00000070: 0x780e0000: 3DSTATE_CC_STATE_POINTERS 0x00000074: 0x00000001: pointer to COLOR_CALC_STATE at 0x00000000 (changed) 0x00000078: 0x7a000003: PIPE_CONTROL 0x0000007c: 0x00101000: no write, cs stall, render target cache flush, 0x00000080: 0x00000000: destination address 0x00000084: 0x00000000: immediate dword low 0x00000088: 0x00000000: immediate dword high 0x0000008c: 0x05000000: MI_BATCH_BUFFER_END intel_do_flush_locked failed: Invalid argument
Looks like the length field of the MI_STORE_REGISTER_MEM is incorrect in the cmdparser as the next instruction it parses is the target address. The regression is likely to be commit f1afe24f0e736b9d7f2275e2b1504af3fe612f2a Author: Arun Siluvery <arun.siluvery@linux.intel.com> Date: Tue Aug 4 16:22:20 2015 +0100 drm/i915: Change SRM, LRM instructions to use correct length which ignored the length bias when setting the fixed length. %$£$!
http://patchwork.freedesktop.org/patch/58513/
Works again. (Got to wonder how that regression wasn't caught automatically, given that it had an ubiquitous effect.)
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.