oenig, Christian
Sent: Tuesday, June 4, 2024 4:07 AM
To: Liu, Shaoyun ; Christian König
; Li, Yunxiang (Teddy) ;
amd-gfx@lists.freedesktop.org; Deucher, Alexander ;
Xiao, Hua
Subject: Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
Hi Shaoyun,
see inline.
Am 03.06.24 um
nt: Monday, June 3, 2024 6:59 AM
To: Liu, Shaoyun ; Christian König ; Li,
Yunxiang (Teddy) ; amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Xiao, Hua
Subject: Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
Hi Shaoyun,
yes my thinking goes into the same direction. The
ddy) ;
amd-gfx@lists.freedesktop.org; Deucher, Alexander ;
Xiao, Hua
Subject: Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
Hi Shaoyun,
yes my thinking goes into the same direction. The basic problem here is that we
are trying to stuff two different information into the same
ay, May 29, 2024 11:19 AM
To: Li, Yunxiang (Teddy) ; Koenig, Christian
; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
Am 29.05.24 um 16:48 schrieb Li, Yunxiang (Teddy):
[AMD Official Use Only - AMD Internal Distribution Only]
Ye
d-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
Am 29.05.24 um 16:48 schrieb Li, Yunxiang (Teddy):
> [AMD Official Use Only - AMD Internal Distribution Only]
>
>> Yeah, I know. That's one of the reason I've pointed out
Am 29.05.24 um 16:48 schrieb Li, Yunxiang (Teddy):
[AMD Official Use Only - AMD Internal Distribution Only]
Yeah, I know. That's one of the reason I've pointed out on the patch adding
that that this behavior is actually completely broken.
If you run into issues with the MES because of this the
[AMD Official Use Only - AMD Internal Distribution Only]
> Yeah, I know. That's one of the reason I've pointed out on the patch adding
> that that this behavior is actually completely broken.
>
> If you run into issues with the MES because of this then please suggest a
> revert of that patch.
I t
Am 29.05.24 um 16:31 schrieb Li, Yunxiang (Teddy):
[Public]
The problem is that we don't force complete the non scheduler rings, e.g. MES,
KIQ etc...
Try to remove this check here from the loop in
amdgpu_device_pre_asic_reset():
if (!amdgpu_ring_sched_ready(ring))
[Public]
> The problem is that we don't force complete the non scheduler rings, e.g. MES,
> KIQ etc...
>
> Try to remove this check here from the loop in
> amdgpu_device_pre_asic_reset():
>
> if (!amdgpu_ring_sched_ready(ring))
> continue;
Ah, I see. Thou
Am 29.05.24 um 15:44 schrieb Li, Yunxiang (Teddy):
[AMD Official Use Only - AMD Internal Distribution Only]
I don't think trying to add some reset handling here makes sense in the first
place.
Part of the reset/recovery procedure is to signal all fence and that includes
the one we are waiting
[AMD Official Use Only - AMD Internal Distribution Only]
> I don't think trying to add some reset handling here makes sense in the first
> place.
> Part of the reset/recovery procedure is to signal all fence and that includes
> the one we are waiting for here.
> So this wait should return immedi
Am 29.05.24 um 15:22 schrieb Li, Yunxiang (Teddy):
[Public]
It's perfectly possible that the reset has already started before we enter the
function.
Yeah, this could and does happen, but it just means we are back to the old behavior. I
guess I could use "can I take the read side lock?" to te
[Public]
> It's perfectly possible that the reset has already started before we enter
> the function.
Yeah, this could and does happen, but it just means we are back to the old
behavior. I guess I could use "can I take the read side lock?" to test if the
function is called outside of reset or
Am 28.05.24 um 19:23 schrieb Yunxiang Li:
If a reset is triggered, there's no point in waiting for the fence back
anymore, it just makes the reset code wait for a long time for the
reset_domain read lock to be dropped.
This also makes our reply to host FLR fast enough so the host doesn't
timeout
14 matches
Mail list logo
