答复: [PATCH] drm/amdgpu/virt: fix double kfree on bo_va

thanks for this catch! Reviewed-by: Monk Liu <monk@amd.com> 发件人: Colin King <colin.k...@canonical.com> 发送时间: 2017年2月4日 4:23:42 收件人: Deucher, Alexander; Koenig, Christian; David Airlie; Liu, Monk; Yu, Xiangliang; amd-...@lists.freedesktop.or

[PATCH 1/4] drm/amdgpu: clear RB at ring init

:34 PM To: Alex Deucher Cc: dri-devel at lists.freedesktop.org; Liu, Monk Subject: Re: [PATCH 1/4] drm/amdgpu: clear RB at ring init On 02.06.2016 07:27, Alex Deucher wrote: > From: Monk Liu > > This help fix reloading driver hang issue of SDMA ring. > > Signed-off-by: Monk Li

Re: [PATCH 1/1] drm/ttm: Fix accounting error when fail to get pages for pool

Reviewed-by: Monk Liu <monk@amd.com> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Xiangliang.Yu <xiangliang...@amd.com> Sent: Wednesday, August 16, 2017 3:20:46 PM To: a...@linux-foundation.org; labb...@redh

Re: [PATCH 2/7] drm/qxl: fix incorrect use of the lru_lock

Ack-by: Monk.Liu From: amd-gfx on behalf of Christian König Sent: Tuesday, August 8, 2017 4:14:46 PM To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Dave

Re: [PATCH] drm/ttm: fix memory leak while individualizing BOs

verified work, Reviewed-by: Monk Liu <monk@amd.com> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Christian König <deathsim...@vodafone.de> Sent: Wednesday, September 13, 2017 4:47:34 PM To: amd-...@lists.freedesk

RE: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver

+ Horace -Original Message- From: Colin King [mailto:colin.k...@canonical.com] Sent: 2017年11月11日 19:51 To: Deucher, Alexander <alexander.deuc...@amd.com>; Koenig, Christian <christian.koe...@amd.com>; David Airlie <airl...@linux.ie>; Liu, Monk <monk@amd

RE: [PATCH 0/2] Move scheduler out of AMDGPU

I'm wondering if GPU reset still work after this home move ... -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Friday, December 1, 2017 11:55 PM To: Lucas Stach ; Deucher, Alexander

Re: reservation questions

&& dma_fence_is_signaled(old_fence)) { signaled = old_fence; signaled_idx = i; } } see that old_fence is get from fobj, and fobj is from reservation_object_get_list(obj) in outside, which is obj->fence, and in add_excl_fence, all dma_fence in obj->f

Re: reservation questions

t; Sent: Tuesday, March 6, 2018 6:10:21 PM To: Liu, Monk; dri-devel@lists.freedesktop.org; Koenig, Christian Subject: Re: reservation questions Quoting Liu, Monk (2018-03-06 09:45:19) > call reservation_object_add_excl_fence, > it set obj->fence->shared_count to 0, and put all sha

Re: reservation questions

ok, that's good point ... From: Koenig, Christian Sent: Tuesday, March 6, 2018 6:42:44 PM To: Liu, Monk; Chris Wilson; dri-devel@lists.freedesktop.org Subject: Re: reservation questions Hi Monk, that is to remove the problem that allocating memory could fail

Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

okay From: Chris Wilson <ch...@chris-wilson.co.uk> Sent: Tuesday, March 6, 2018 4:24:21 PM To: Liu, Monk; dri-de...@freedesktop.org Cc: Liu, Monk Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2) Quoting Monk Liu (2018-03-06

reservation questions

Hi Christian & Chris two question regarding resv: 1) considering below sequence: call reservation_object_add_shared_fence, now assume old->shared_count is now 3 call reservation_object_add_shared_fence, now assume old->shared_count is now 4, call reservation_object_reserve_shared, now

Re: reservation questions

m: Koenig, Christian Sent: Tuesday, March 6, 2018 6:05:27 PM To: Liu, Monk; dri-devel@lists.freedesktop.org; Chris Wilson Subject: Re: reservation questions Am 06.03.2018 um 10:56 schrieb Liu, Monk: sorry, I have some mistake in previous thread, correct it as followings. 1) considering below sequen

RE: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

mer...@gmail.com] Sent: 2018年2月28日 16:27 To: Liu, Monk <monk@amd.com>; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available Am 28.02.2018 um 07:44 schrieb Monk Liu: > under below scen

RE: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

s a little weired to me ... especially this staged part ... Thanks /Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年3月5日 19:22 To: Liu, Monk <monk@amd.com>; Koenig, Christian <christian.koe...@amd.com>; dri-dev

RE: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

so why we kfree on it 2) in fact, amdgpu can hit the case that obj->staged is not NULL in reserved_shared(), don't know how it lead here Any thought ? /Monk -Original Message- From: Koenig, Christian Sent: 2018年3月5日 19:29 To: Liu, Monk <monk@amd.com>; dri-devel@lists.fre

RE: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

Can you give more details ? thanks /Monk -Original Message- From: Koenig, Christian Sent: 2018年3月5日 19:39 To: Liu, Monk <monk@amd.com>; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] dma-buf/reservation: shouldn't kfree staged whe

RE: [PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace

Yeah, right -Original Message- From: Zhou, David(ChunMing) Sent: 2018年3月6日 11:38 To: Liu, Monk <monk@amd.com>; dri-devel@lists.freedesktop.org Subject: Re: [PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace On 2018年03月06日 11:09, Monk Liu wrote: &g

RE: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

Make sense, will give v3 -Original Message- From: Zhou, David(ChunMing) Sent: 2018年3月6日 14:08 To: Liu, Monk <monk@amd.com>; Zhou, David(ChunMing) <david1.z...@amd.com>; dri-de...@freedesktop.org Subject: Re: [PATCH] dma-buf/reservation: should keep later one in

Re: [PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace

why? is there a design doc mentioned for this on reservation ? From: Christian K?nig <ckoenig.leichtzumer...@gmail.com> Sent: Tuesday, March 6, 2018 4:03:39 PM To: Liu, Monk; dri-devel@lists.freedesktop.org Subject: Re: [PATCH] dma-buf/reservation: shoul

RE: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

k into fobj->shared[++j], so in the end Obj->fence will point to fobj, and original old would be rcu_kfree() No additional action actually needed... /Monk -Original Message----- From: Zhou, David(ChunMing) Sent: 2018年3月6日 12:25 To: Liu, Monk <monk@amd.com>; dri-de...@freedesktop.o

Re: reservation questions

for the explanation /Monk From: Koenig, Christian Sent: Tuesday, March 6, 2018 7:11:50 PM To: Liu, Monk Cc: dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org>; Chris Wilson Subject: Re: reservation questions Hi Monk, your check isn't

Re: reservation questions

From: Koenig, Christian Sent: Tuesday, March 6, 2018 7:11:50 PM To: Liu, Monk Cc: dri-devel@lists.freedesktop.org; Chris Wilson Subject: Re: reservation questions Hi Monk, your check isn't correct because you still haven't understood the semantics here

RE: reservation questions

when we add an excl fence to resv, how to deal with shared ? current logic is just put the all do we need to wait on their signaling before putting them ? thanks /Monk From: Liu, Monk Sent: 2018年3月6日 17:57 To: dri-devel@lists.freedesktop.org; Chris Wilson <ch...@chris-wilson.co.uk>;

Re: reservation questions

[ 105.704982] RIP: reservation_object_add_excl_fence+0x9c/0xf0 RSP: b1204159f9f0 the assumption that all shared fences should be signaled before adding excl fence looks not 100% guaranteed in LKG, Going to take a deep look ... /Monk ________ From: Liu, Monk Sent: Tuesday, Mar

RE: FW: [PATCH] drm: should break if already get the best size

nt: Friday, November 23, 2018 5:03 PM To: Liu, Monk ; dri-devel@lists.freedesktop.org Subject: Re: FW: [PATCH] drm: should break if already get the best size Quoting Liu, Monk (2018-11-23 08:02:11) > > > -Original Message- > From: amd-gfx On Behalf Of > Monk Liu > Sent: T

FW: [PATCH] drm: should break if already get the best size

Hi Chris Please check the sanity test of the patch from Rex /Monk From: Zhu, Rex Sent: Friday, November 23, 2018 5:45 PM To: Liu, Monk ; amd-...@lists.freedesktop.org Subject: Re: [PATCH] drm: should break if already get the best size Tested-by: Rex Zhu mailto:rex@amd.com>> W

FW: [PATCH] drm: should break if already get the best size

-Original Message- From: amd-gfx On Behalf Of Monk Liu Sent: Thursday, November 22, 2018 8:33 PM To: amd-...@lists.freedesktop.org Cc: Liu, Monk Subject: [PATCH] drm: should break if already get the best size Signed-off-by: Monk Liu --- drivers/gpu/drm/drm_mm.c | 2 ++ 1 file

FW: [PATCH] drm: should break if already get the best size

-Original Message- From: amd-gfx On Behalf Of Monk Liu Sent: Thursday, November 22, 2018 8:33 PM To: amd-...@lists.freedesktop.org Cc: Liu, Monk Subject: [PATCH] drm: should break if already get the best size Signed-off-by: Monk Liu --- drivers/gpu/drm/drm_mm.c | 2 ++ 1 file

RE: FW: [PATCH] drm: should break if already get the best size

There is no checks at all in this best_hole() ... can you review the patch again ? /Monk -Original Message- From: Chris Wilson Sent: Friday, November 23, 2018 5:34 PM To: Liu, Monk ; dri-devel@lists.freedesktop.org Subject: RE: FW: [PATCH] drm: should break if already get the best size

RE: [PATCH] drm: should return upon the best size(v3)

nig Sent: Tuesday, November 27, 2018 8:54 PM To: Chris Wilson ; Liu, Monk ; dri-de...@freedesktop.org Subject: Re: [PATCH] drm: should return upon the best size(v3) Am 27.11.18 um 11:00 schrieb Christian König: > Am 27.11.18 um 10:20 schrieb Chris Wilson: >> Quoting Monk Liu (2018-11

RE: [PATCH] drm: should return upon the best size(v3)

age- From: Christian König Sent: Tuesday, November 27, 2018 9:48 PM To: Liu, Monk ; Koenig, Christian ; Chris Wilson ; dri-de...@freedesktop.org Subject: Re: [PATCH] drm: should return upon the best size(v3) Am 27.11.18 um 14:40 schrieb Liu, Monk: >> A node with the searched size is not

RE: [PATCH] drm: should return upon the best size(v3)

Oh, yeah ... I find one aspect, we need to consider "range_start" and "range_end" Yeah, you guys are right, cool /Monk -Original Message- From: Liu, Monk Sent: Tuesday, November 27, 2018 10:10 PM To: Koenig, Christian ; Chris Wilson ; dri-de...@freedesktop.org

RE: [PATCH] drm/scheduler: use job count instead of peek

Reviewed-by: monk@amd.com _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Friday, August 9, 2019 11:31 PM To: Grodzovsky, Andrey ; dri-devel@lists.freedesktop.org; Liu, Monk ; Deng, Emily Subject: [PATCH

RE: [PATCH 3/5] drm/amdgpu: Paper over the drm_driver mangling for virt

, Andrey ; Tuikov, Luben ; Thomas Zimmermann ; Liu, Monk ; Yintian Tao ; Li, Dennis ; Liu, Shaoyun ; Zhang, Bokun ; Yang, Stanley ; Sheng, Wenhui ; Gong, Curry ; Daniel Vetter Subject: [PATCH 3/5] drm/amdgpu: Paper over the drm_driver mangling for virt Prep work to make drm_device->driver co

RE: 回复: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak

, March 26, 2021 10:51 PM To: Liu, Monk ; Zhang, Jack (Jian) ; Grodzovsky, Andrey ; Christian König ; dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Deng, Emily ; Rob Herring ; Tomeu Vizoso ; Steven Price Cc: Zhang, Andy ; Jiang, Jerry (SW) Subject: Re: 回复: [PATCH v3] drm

回复: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak

lease understand our painful here /Monk -邮件原件- 发件人: Koenig, Christian 发送时间: 2021年3月26日 17:06 收件人: Zhang, Jack (Jian) ; Grodzovsky, Andrey ; Christian König ; dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Liu, Monk ; Deng, Emily ; Rob Herring ; Tomeu Vizoso ; Steven

RE: [PATCH v2] Revert "drm/scheduler: Avoid accessing freed bad job."

impact performance since in that scenario There was already something wrong/stuck on that ring/scheduler Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: Liu, Monk Sent: Thursday, August 19

RE: [PATCH v2] Revert "drm/scheduler: Avoid accessing freed bad job."

ud-GPU Core team -- -Original Message- From: Daniel Vetter Sent: Wednesday, August 18, 2021 10:43 PM To: Grodzovsky, Andrey Cc: Daniel Vetter ; Alex Deucher ; Chen, JingWen ; Maling list - DRI developers ; amd-gfx list ; Liu, Monk ; Koenig, Chri

RE: [PATCH v2] Revert "drm/scheduler: Avoid accessing freed bad job."

-- -Original Message- From: Grodzovsky, Andrey Sent: Friday, August 20, 2021 10:07 PM To: Liu, Monk ; Daniel Vetter ; Koenig, Christian Cc: Alex Deucher ; Chen, JingWen ; Maling list - DRI developers ; amd-gfx list Subject: Re: [PATCH v2] Revert "drm/scheduler: Avoi

RE: [PATCH] drm/sched: fix the bug of time out calculation(v3)

-- -Original Message- From: Grodzovsky, Andrey Sent: Friday, August 27, 2021 4:14 AM To: Liu, Monk ; amd-...@lists.freedesktop.org; Koenig, Christian Cc: dri-devel@lists.freedesktop.org Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v3

RE: [PATCH] drm/sched: fix the bug of time out calculation(v3)

al Message- From: Christian König Sent: Friday, August 27, 2021 2:12 PM To: Grodzovsky, Andrey ; Liu, Monk ; amd-...@lists.freedesktop.org; Koenig, Christian Cc: dri-devel@lists.freedesktop.org Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v3) I d

RE: [PATCH] drm/sched: fix the bug of time out calculation(v3)

et(>_score, 0); atomic64_set(>job_id_count, 0); Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: Christian König Sent: Thursday, August 26, 2021 8:38 PM To: Liu, Monk ; amd-...@lists.freedesktop.o

RE: [PATCH 1/2] drm/sched: fix the bug of time out calculation(v3)

Sent: Tuesday, August 31, 2021 6:36 PM To: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org; Liu, Monk Subject: [PATCH 1/2] drm/sched: fix the bug of time out calculation(v3) issue: in cleanup_job the cancle_delayed_work will cancel a TO timer even the its corresponding job is still

RE: [PATCH 2/2] drm/sched: serialize job_timeout and scheduler

t. Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: Daniel Vetter Sent: Tuesday, August 31, 2021 9:02 PM To: Liu, Monk Cc: amd-...@lists.freedesktop.org; dri-devel@lists.fre

[diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

[AMD Official Use Only] Hi Daniel/Christian/Andrey It looks the voice from you three are spread over those email floods to me, the feature we are working on (diagnostic TDR scheme) is pending there for more than 6 month (we started it from feb 2021). Honestly speaking the email ways that we

RE: [PATCH] drm/sched: fix the bug of time out calculation(v3)

-- Monk Liu | Cloud-GPU Core team -- -Original Message- From: Daniel Vetter Sent: Tuesday, August 31, 2021 9:09 PM To: Koenig, Christian Cc: Grodzovsky, Andrey ; Christian König ; Liu, Monk ; amd

RE: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

n it so sched_main won't free it in parallel ... What do you think ? Thanks -- Monk Liu | Cloud-GPU Core team ---------- From: Liu, Monk Sent: Wednesday, September 1, 2021 9:23 AM To: Koenig, Christian ; Grodzovsky, Andrey

RE: [PATCH 2/2] drm/sched: serialize job_timeout and scheduler

se common members like sched_job. (due to spin_lock is off before running into vendor's calback) Hope I explained ourselves well enough. Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message----- From: Dan

RE: [PATCH 2/2] drm/sched: serialize job_timeout and scheduler

[AMD Official Use Only] Okay, I will reprepare this patch Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: Daniel Vetter Sent: Tuesday, August 31, 2021 9:02 PM To: Liu, Monk Cc: amd

RE: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

Of Daniel Vetter Sent: Wednesday, September 1, 2021 4:18 PM To: Liu, Monk Cc: Koenig, Christian ; Grodzovsky, Andrey ; Chen, JingWen ; DRI Development ; amd-...@lists.freedesktop.org Subject: Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread Hi Monk, On W

RE: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

eview. Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: amd-gfx On Behalf Of Daniel Vetter Sent: Wednesday, September 1, 2021 4:18 PM To: Liu, Monk Cc: Koenig, Christian ; Grodzovsky, Andrey ; Chen, JingWen ; DRI Develo

RE: [PATCH] drm/sched: fix the bug of time out calculation(v2)

re, the whole counting is repeated from zero and inaccurate at all Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: Grodzovsky, Andrey Sent: Thursday, August 26, 2021 2:20 AM To:

RE: [PATCH] drm/sched: fix the bug of time out calculation(v2)

uot; job is already started on HW... that's why I use mod_delayed_work. But I can change it to "cancel and queue" approach if you have concern. Thanks -- Monk Liu | Cloud-GPU Core team -- -----Origina

RE: [PATCH] drm/sched: fix the bug of time out calculation(v2)

Monk Liu | Cloud-GPU Core team -- -Original Message- From: Grodzovsky, Andrey Sent: Thursday, August 26, 2021 11:05 AM To: Liu, Monk ; Christian König ; amd-...@lists.freedesktop.org; dri-devel Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v2) On 2021-08

RE: [PATCH] drm/sched: fix the bug of time out calculation(v3)

- -Original Message- From: Christian König Sent: Thursday, August 26, 2021 6:09 PM To: Liu, Monk ; amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v3) Am 26.08.21 um 06:55

RE: [PATCH v2] Revert "drm/scheduler: Avoid accessing freed bad job."

aled. Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: Daniel Vetter Sent: Thursday, August 19, 2021 5:31 PM To: Grodzovsky, Andrey Cc: Daniel Vetter ; Alex Deucher ; Chen, JingWen ; Maling list

RE: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

er 2, 2021 2:51 AM To: Alex Deucher Cc: Liu, Monk ; Daniel Vetter ; Koenig, Christian ; Grodzovsky, Andrey ; Chen, JingWen ; DRI Development ; amd-...@lists.freedesktop.org Subject: Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread On Thu, 2 Sept 2021 at 0

RE: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

Vetter Sent: Friday, September 3, 2021 12:11 AM To: Koenig, Christian Cc: Liu, Monk ; Dave Airlie ; Alex Deucher ; Grodzovsky, Andrey ; Chen, JingWen ; DRI Development ; amd-...@lists.freedesktop.org Subject: Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread On

RE: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV

amd-...@lists.freedesktop.org Cc: dan...@ffwll.ch; Liu, Monk ; Chen, Horace Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV Am 22.12.21 um 23:14 schrieb Andrey Grodzovsky: > Since now flr work is serialized against GPU resets there is no need > for this. >

RE: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV

, January 4, 2022 6:19 PM To: Chen, JingWen ; Christian König ; Grodzovsky, Andrey ; Deng, Emily ; Liu, Monk ; dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Chen, Horace ; Chen, JingWen Cc: dan...@ffwll.ch Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection