Created attachment 138657 [details] i915 error state While running Vkcube, I get hangs after a few seconds. The command stream is full of invalid instructions : --- batch buffer (rcs0) at 0x00000000 00021000 unknown instruction ff7b7b7b unknown instruction ff7b7b7b unknown instruction ff7b7b7b Vkcube also ends up crashing and under valgrind I managed to get this couple of backtraces : ==14443== Invalid free() / delete / delete[] / realloc() ==14443== at 0x7B6EA11: anv_state_stream_finish (anv_allocator.c:885) ==14443== by 0x7B7C19C: anv_cmd_buffer_reset (anv_cmd_buffer.c:299) ==14443== by 0x7B7D7DA: anv_ResetCommandPool (anv_cmd_buffer.c:881) ==14443== by 0x58FBEE8: vkResetCommandPool (trampoline.c:1644) ==14443== by 0x1114AD: render_cube (cube.c:442) ==14443== by 0x10FA8C: mainloop_wayland (main.c:1185) ==14443== by 0x1100C8: mainloop (main.c:1362) ==14443== by 0x1101DA: main (main.c:1392) ==14443== Address 0xff7b7b7bff7b7b7b is not stack'd, malloc'd or (recently) free'd ==14443== vkcube: ../src/intel/vulkan/anv_allocator.c:817: anv_state_pool_free_no_vg: Assertion `util_is_power_of_two_or_zero(state.alloc_size)' failed. ==14443== ==14443== Process terminating with default action of signal 6 (SIGABRT) ==14443== at 0x5EEEE7B: raise (raise.c:51) ==14443== by 0x5EF0230: abort (abort.c:79) ==14443== by 0x5EE79D9: __assert_fail_base (assert.c:92) ==14443== by 0x5EE7A51: __assert_fail (assert.c:101) ==14443== by 0x7B6E64E: anv_state_pool_free_no_vg (anv_allocator.c:817) ==14443== by 0x7B6EAB4: anv_state_stream_finish (anv_allocator.c:887) ==14443== by 0x7B7C19C: anv_cmd_buffer_reset (anv_cmd_buffer.c:299) ==14443== by 0x7B7D7DA: anv_ResetCommandPool (anv_cmd_buffer.c:881) ==14443== by 0x58FBEE8: vkResetCommandPool (trampoline.c:1644) ==14443== by 0x1114AD: render_cube (cube.c:442) ==14443== by 0x10FA8C: mainloop_wayland (main.c:1185) ==14443== by 0x1100C8: mainloop (main.c:1362) Unfortunately it seems it's just valgrind rereading the corrupted batchbuffer, so still not sure who's responsible for the corruption. This is using mesa master : commit 7fe586f6fb69cd829d687dd58562ef5922667905 Author: Samuel Pitoiset <samuel.pitoiset@gmail.com> Date: Thu Apr 5 10:27:22 2018 +0200 radv: only enable PERFECT_ZPASS_COUNTS for precision occlusion queries And Vkcube master : commit 0062eec985134a0bd1e85588c34bf0d55ebf51eb Author: Bas Nieuwenhuizen <basni@chromium.org> Date: Sun Feb 25 02:43:48 2018 +0100 Link with libm.
And kernel : commit 277ab5abc68df2f6f8fac7a46e50105b6648f432 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Mar 22 17:47:07 2018 +0200 drm/i915: Don't spew errors when resetting HDMI scrambling/bit clock ratio fails Might not be a userspace issue :/
Turns out 0xff7b7b7b is the background color of Vkcube. A bit less of a mystery now.
False alarm, this is just an application issue. I should have run the debug layer : DS(ERROR / SPEC): object: 0x560b659fb8a0 type: 6 msgNum: 847249488 - Attempt to reset command pool with command buffer (0x560b659fb8a0) which is in use. The spec valid usage text states 'All VkCommandBuffer objects allocated from commandPool must not be in the pending state' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkResetCommandPool-commandPool-00040) Basically rewriting the batchbuffer while it's being executed.
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.