Bug 105930

Summary:	[KBL] Hang when running Vkcube
Product:	Mesa	Reporter:	Lionel Landwerlin <lionel.g.landwerlin>
Component:	Drivers/Vulkan/intel	Assignee:	Lionel Landwerlin <lionel.g.landwerlin>
Status:	RESOLVED NOTOURBUG	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	normal
Priority:	medium	CC:	intel-gfx-bugs, jason
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	i915 error state

Description Lionel Landwerlin 2018-04-06 16:38:50 UTC

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.

Comment 1 Lionel Landwerlin 2018-04-06 16:41:42 UTC

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 :/

Comment 2 Lionel Landwerlin 2018-04-06 20:43:40 UTC

Turns out 0xff7b7b7b is the background color of Vkcube.
A bit less of a mystery now.

Comment 3 Lionel Landwerlin 2018-04-07 00:25:34 UTC

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.