dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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