AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Harry Wentland" <harry.wentland@amd.com>,
	"Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>,
	"Yu, Lang" <Lang.Yu@amd.com>
Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: Questions about KMS flip
Date: Fri, 12 Nov 2021 17:10:27 +0100	[thread overview]
Message-ID: <58097218-40dd-55fd-32d2-2a299d39230f@daenzer.net> (raw)
In-Reply-To: <735f8781-982b-a09f-32fe-fded0024a587@gmail.com>

On 2021-11-12 16:03, Christian König wrote:
> Am 12.11.21 um 15:30 schrieb Michel Dänzer:
>> On 2021-11-12 15:29, Michel Dänzer wrote:
>>> On 2021-11-12 13:47, Christian König wrote:
>>>> Anyway this unfortunately turned out to be work for Harray and Nicholas. In detail it's about this bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=214621
>>>>
>>>> Lang was able to reproduce the issue and narrow it down to the pin in amdgpu_display_crtc_page_flip_target().
>>>>
>>>> In other words we somehow have an unbalanced pinning of the scanout buffer in DC.
>>> DC doesn't use amdgpu_display_crtc_page_flip_target AFAICT. The corresponding pin with DC would be in dm_plane_helper_prepare_fb, paired with the unpin in
>>> dm_plane_helper_cleanup_fb.
>>>
>>>
>>> With non-DC, the pin in amdgpu_display_crtc_page_flip_target is paired with the unpin in dm_plane_helper_cleanup_fb
>> This should say amdgpu_display_unpin_work_func.
> 
> Ah! So that is the classic (e.g. non atomic) path?

Presumably.


>>> & dce_v*_crtc_disable. One thing I notice is that the pin is guarded by if (!adev->enable_virtual_display), but the unpins seem unconditional. So could this be about virtual display, and the problem is actually trying to unpin a BO that was never pinned?
> 
> Nope, my educated guess is rather that we free up the BO before amdgpu_display_unpin_work_func is called.
> 
> E.g. not pin unbalance, but rather use after free.

amdgpu_display_crtc_page_flip_target calls amdgpu_bo_ref(work->old_abo), and amdgpu_display_unpin_work_func calls amdgpu_bo_unref(&work->old_abo) only after amdgpu_bo_unpin. So what you describe could only happen if there's an imbalance elsewhere such that amdgpu_bo_unref is called more often than amdgpu_bo_ref, or maybe if amdgpu_bo_reserve fails in amdgpu_display_unpin_work_func (in which case the "failed to reserve buffer after flip" error message should appear in dmesg).


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer

  reply	other threads:[~2021-11-12 16:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <579d0f44-bb85-11b2-d326-35a0b7c5d0de@amd.com>
     [not found] ` <5c242319-ade3-5621-6429-f77b17c34de5@amd.com>
     [not found]   ` <YYV0W1CxT5torU7u@phenom.ffwll.local>
     [not found]     ` <64e70779-7c33-7849-aa29-aeaee4a89005@amd.com>
     [not found]       ` <YYk7SkflDx8ToqYG@phenom.ffwll.local>
     [not found]         ` <4ba7e3f8-7956-882a-6888-57e2448b907d@amd.com>
     [not found]           ` <YYvIfXy9bwPokiK9@phenom.ffwll.local>
2021-11-12 12:47             ` Questions about KMS flip 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 [this message]
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=58097218-40dd-55fd-32d2-2a299d39230f@daenzer.net \
    --to=michel@daenzer.net \
    --cc=Lang.Yu@amd.com \
    --cc=Nicholas.Kazlauskas@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    /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