It fixed an intermittent failure to allocate page tables in the page fault handler (turning retry faults into no-retry faults). I'm not sure if this caused real problems. I think it could potentially result in fault storms and a failure to report page faults properly. I'm not sure if it's a regression or was always present. So I'm not sure if it's an urgent fix.
Regards, Felix
Am 2021-03-05 um 2:56 a.m. schrieb Christian König:
Am 05.03.21 um 02:21 schrieb Felix Kuehling:
Am 2021-03-01 um 10:09 a.m. schrieb Christian König:
Am 27.02.21 um 04:45 schrieb Felix Kuehling:
Move fences that have already signaled should not prevent memory allocations with no_wait_gpu.
Signed-off-by: Felix Kuehling Felix.Kuehling@amd.com
Reviewed-by: Christian König christian.koenig@amd.com
I work on this on Alex's rebased amd-staging-drm-next. Should this go into any other branches?
I have a branch with stuff for 5.13 which I want to push to drm-misc-next as soon as 5.12-rc1 is out.
Going to add this one here to that collection as well unless you say that this is really a bug fix and we need it earlier.
Regards, Christian.
Thanks, Felix
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 3a10bebb75d6..de1ec838cf8b 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -730,8 +730,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo, return 0; if (no_wait_gpu) { + ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY; dma_fence_put(fence); - return -EBUSY; + return ret; } dma_resv_add_shared_fence(bo->base.resv, fence);