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
