Dmitry Osipenko <dmitry.osipe...@collabora.com> writes:
> On 6/5/24 17:47, Alex Bennée wrote:
> ....
>> I'm guessing some sort of resource leak, if I run vkcube-wayland in the
>> guest it complains about being stuck on a fence with the iterator going
>> up. However on the host I see:
>>
<snip>
>>
>> The backtrace (and the 18G size of the core file!) indicates a leak:
>
> The unmap debug-assert tells that BO wasn't mapped because mapping
> failed, likely due to OOM. You won't hit this abort with a release build
> of libvirglrenderer.
AFAIK I should be building a release build (or at least I hope that is
what the wrapper I posted does):
Message-Id: <20240605133527.529950-1-alex.ben...@linaro.org>
Date: Wed, 5 Jun 2024 14:35:27 +0100
Subject: [RFC PATCH] subprojects: add a wrapper for libvirglrenderer
From: =?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.ben...@linaro.org>
Maybe I need to explicitly set builtype=release in the default options?
> The leak likely happens due to unsignalled fence.
>
> Please try to run vkcube with disabled fence-feedback feature:
>
> # VN_PERF_NO_FENCE_FEEDBACK=1 vkcube-wayland
>
> It fixes hang for me. We had problems with combination of this Venus
> optimization feature + Intel ANV driver for a long time and hoped that
> it's fixed by now, apparently the issue was only masked.
That doesn't help, still causes the crash:
virtio_gpu_fence_ctrl fence 0xdfd, type 0x204
virtio_gpu_fence_ctrl fence 0xdfe, type 0x207
virtio_gpu_fence_ctrl fence 0xdff, type 0x207
virtio_gpu_fence_ctrl fence 0xe00, type 0x207
virtio_gpu_fence_ctrl fence 0xe01, type 0x207
virtio_gpu_fence_ctrl fence 0xe02, type 0x207
virtio_gpu_fence_ctrl fence 0xe03, type 0x207
virtio_gpu_fence_resp fence 0xdfd
virtio_gpu_fence_resp fence 0xdfe
virtio_gpu_fence_resp fence 0xdff
virtio_gpu_fence_resp fence 0xe00
virtio_gpu_fence_resp fence 0xe01
virtio_gpu_fence_resp fence 0xe02
virtio_gpu_fence_resp fence 0xe03
stats: vq req 100, 7 -- 3D 25 (19560)
vrend_renderer_resource_unmap: invalid bits 0x83
virgl_renderer_resource_unmap: unexpected ret = -22, pipe:0x555559e5d0c0
fd_type:0
Thread 1 "qemu-system-aar" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6,
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
Which I think means VREND_STORAGE_GL_MEMOBJ | VREND_STORAGE_GL_TEXTURE |
VREND_STORAGE_GUEST_MEMORY
(I note the sense of has_bits is meant to be mask, bit but I don't think
that makes any difference)
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
