From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Michel Dänzer" <michel@daenzer.net>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>
Subject: Re: Questions about KMS flip
Date: Wed, 10 Nov 2021 14:26:21 +0100 [thread overview]
Message-ID: <YYvIfXy9bwPokiK9@phenom.ffwll.local> (raw)
In-Reply-To: <4ba7e3f8-7956-882a-6888-57e2448b907d@amd.com>
On Wed, Nov 10, 2021 at 11:18:02AM +0100, Christian König wrote:
> 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?
stack depot, not stuff it into a string. stack depot is a lot more
efficient and capturing backtraces, since it de-dupes and hashes and all
you need is a pointer iirc. linux/stackdepot.h for interface, I think we
recently gained a few more users of it in drm. It's _really_ nifty.
-Daniel
>
> 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.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2021-11-10 13:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 12:51 Questions about KMS flip Christian König
2021-11-04 16:44 ` Harry Wentland
2021-11-05 12:20 ` Ville Syrjälä
2021-11-05 18:13 ` Daniel Vetter
2021-11-08 7:44 ` Christian König
2021-11-08 14:59 ` Daniel Vetter
2021-11-10 10:18 ` Christian König
2021-11-10 13:26 ` Daniel Vetter [this message]
2021-11-12 12:47 ` Christian König
2021-11-12 14:29 ` Michel Dänzer
2021-11-12 14:30 ` Michel Dänzer
2021-11-12 15:03 ` Christian König
2021-11-12 16:10 ` Michel Dänzer
2021-11-15 6:41 ` Lang Yu
2021-11-15 8:38 ` Michel Dänzer
2021-11-15 9:04 ` Lang Yu
2021-11-15 9:49 ` Michel Dänzer
2021-11-15 11:31 ` Lang Yu
2021-11-15 12:04 ` Michel Dänzer
2021-11-16 3:27 ` Lang Yu
2021-11-16 7:14 ` Christian König
2021-11-16 8:00 ` Lang Yu
2021-11-16 8:09 ` Christian König
2021-11-16 14:10 ` Alex Deucher
2021-11-16 14:50 ` Michel Dänzer
2021-11-15 7:25 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YYvIfXy9bwPokiK9@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=Nicholas.Kazlauskas@amd.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=michel@daenzer.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox