Am 08.11.21 um 15:59 schrieb Daniel Vetter:
On Mon, Nov 08, 2021 at 08:44:24AM +0100, Christian König wrote:
Am 05.11.21 um 19:13 schrieb Daniel Vetter:
On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
+Nick
It looks to be the old drm_plane_state->fb holds that reference. See dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
Yup plane state holds reference for its entire existing (well this holds
in general as design principle for atomic state structs, just makes life
easier). And the plane state is guaranteed to exist from when we first pin
(prepare_fb plane hook) to when it's getting unpinned (cleanup_fb plane
hook).
Out of curiosity, what's blowing up?
The TTM pin count warning. What happens is that we try to free up a BO while
it is still being pinned.
My best guess is that some DMA-buf client is doing something wrong, but it
could of course also be that the BO was pinned for scanout.
We check in dma_buf_release whether there's anything left over, so I think
the dma-buf scenario is rather unlikely.
That was unfortunately only added quite recently and is currently
backported to older kernels.
I guess worst case we could add a cookie struct to dma_buf_pin that you
need to pass to dma_buf_unpin, and wherein we can capture a backtrace. Or
maybe implement that in ttm even. Otherwise I don't have good ideas.
I was thinking about something similar for ttm_bo_pin().
BTW: How would I do that? I know that dump_stack() prints the current
stack trace into the system log, but how would I get this as string?
Thanks,
Christian.
-Daniel
Christian.
-Daniel
Harry
On 2021-11-04 08:51, Christian König wrote:
Hi guys,
adding the usual suspects which might know that of hand: When we do a KMS page flip, who keeps the reference to the BO while it is scanned out?
We are running into warning backtraces from TTM which look more than odd.
Thanks,
Christian.
