From: "Michel Dänzer" <michel@daenzer.net>
To: Lang Yu <Lang.Yu@amd.com>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>,
"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: Questions about KMS flip
Date: Mon, 15 Nov 2021 09:38:47 +0100 [thread overview]
Message-ID: <cadb9503-b390-e254-ffba-5e2e11f100cc@daenzer.net> (raw)
In-Reply-To: <YZIA/dkvjuMsup24@lang-desktop>
On 2021-11-15 07:41, Lang Yu wrote:
> On Fri, Nov 12, 2021 at 05:10:27PM +0100, Michel DDDnzer wrote:
>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D214621&data=04%7C01%7CLang.Yu%40amd.com%7Cca557eab16864ab544a108d9a5f6f288%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637723302338811983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9oG6k22BVp%2BkSvRX6uMlGXc6G%2BA5UL0Qy3W5iDTpvzs%3D&reserved=0
>>>>>>
>>>>>> 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).
>
>
> Actually, each call to amdgpu_display_crtc_page_flip_target() will
>
> 1, init a work(amdgpu_display_unpin_work_func) to unpin an old buffer
> (crtc->primary->fb), the work will be queued in dce_vX_0_pageflip_irq().
>
> 2, pin a new buffer, assign it to crtc->primary->fb. But how to unpin it?
> Next call.
>
> The problem is the pinned buffer of last call to
> amdgpu_display_crtc_page_flip_target() is not unpinned.
It's unpinned in dce_v*_0_crtc_disable.
I think I've found the problem though: dce_v*_0_crtc_do_set_base pin the BO from target_fb unconditionally, but unpin the BO from the fb parameter only if it's different from the former. So if they're the same, the BO's pin count is incremented by 1.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
next prev parent reply other threads:[~2021-11-15 8:38 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
2021-11-15 6:41 ` Lang Yu
2021-11-15 8:38 ` Michel Dänzer [this message]
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=cadb9503-b390-e254-ffba-5e2e11f100cc@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 \
/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