I'm afraid signalling the fences with an IB test is not reliable. Marek On Wed, Oct 2, 2013 at 3:52 PM, Christian König <deathsimple@xxxxxxxxxxx> wrote: > 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@xxxxxxxxx> schrieb: > >>From: Marek Olšák <marek.olsak@xxxxxxx> >> >>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@xxxxxxx> >>--- >> 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@xxxxxxxxxxxxxxxxxxxxx >>http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
