NAK, after recovering from a lockup the first thing we do is signalling all remaining fences with an IB test.
If we don't recover we indeed signal all fences manually.
Signalling all fences regardless of the outcome of the reset creates problems with both types of partial resets.
Christian.
Marek Olšák maraeo@gmail.com schrieb:
From: Marek Olšák marek.olsak@amd.com
After a lockup, fences are not signalled sometimes, causing the GEM_WAIT_IDLE ioctl to never return, which sometimes results in an X server freeze.
This fixes only one of many deadlocks which can occur during a lockup.
Signed-off-by: Marek Olšák marek.olsak@amd.com
drivers/gpu/drm/radeon/radeon_device.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 841d0e0..7b97baa 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1552,6 +1552,11 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
- mutex_lock(&rdev->ring_lock);
- radeon_fence_driver_force_completion(rdev);
- mutex_unlock(&rdev->ring_lock);
- radeon_pm_suspend(rdev); radeon_suspend(rdev);
-- 1.8.1.2
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel