From: Lang Yu <Lang.Yu@amd.com>
To: Michel DDDnzer <michel@daenzer.net>
Cc: Christian KKKnig <ckoenig.leichtzumerken@gmail.com>,
amd-gfx list <amd-gfx@lists.freedesktop.org>,
"Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Harry Wentland <harry.wentland@amd.com>,
Christian KKKnig <christian.koenig@amd.com>
Subject: Re: Questions about KMS flip
Date: Mon, 15 Nov 2021 14:41:01 +0800 [thread overview]
Message-ID: <YZIA/dkvjuMsup24@lang-desktop> (raw)
In-Reply-To: <58097218-40dd-55fd-32d2-2a299d39230f@daenzer.net>
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 should be an imbalance call to pin/unpin.
>
> --
> Earthling Michel Dänzer | https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com%2F&data=04%7C01%7CLang.Yu%40amd.com%7Cca557eab16864ab544a108d9a5f6f288%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637723302338811983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fJroRJc4SYuUXX1U52X%2FktYpAKaADg3kM9PsONnKu8c%3D&reserved=0
> Libre software enthusiast | Mesa and Xwayland developer
WARNING: multiple messages have this Message-ID (diff)
From: Lang Yu <Lang.Yu@amd.com>
To: Michel DDDnzer <michel@daenzer.net>
Cc: Christian KKKnig <ckoenig.leichtzumerken@gmail.com>,
amd-gfx list <amd-gfx@lists.freedesktop.org>,
"Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Christian KKKnig <christian.koenig@amd.com>
Subject: Re: Questions about KMS flip
Date: Mon, 15 Nov 2021 14:41:01 +0800 [thread overview]
Message-ID: <YZIA/dkvjuMsup24@lang-desktop> (raw)
In-Reply-To: <58097218-40dd-55fd-32d2-2a299d39230f@daenzer.net>
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 should be an imbalance call to pin/unpin.
>
> --
> Earthling Michel Dänzer | https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com%2F&data=04%7C01%7CLang.Yu%40amd.com%7Cca557eab16864ab544a108d9a5f6f288%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637723302338811983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fJroRJc4SYuUXX1U52X%2FktYpAKaADg3kM9PsONnKu8c%3D&reserved=0
> Libre software enthusiast | Mesa and Xwayland developer
next prev parent reply other threads:[~2021-11-15 6:41 UTC|newest]
Thread overview: 28+ 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
2021-11-12 12:47 ` Christian König
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 [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=YZIA/dkvjuMsup24@lang-desktop \
--to=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 \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.