Message ID | 1425503403-5277-1-git-send-email-jan.vesely@rutgers.edu (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
please ignore this patch, see bugzilla for details. sorry for the noise. On Wed, 2015-03-04 at 16:10 -0500, Jan Vesely wrote: > cleanup: target is called before fence_get > Fixes hangs on GPU reset on Turks GPU. > > regression introduced by: > commit dd7cfd641228abb2669d8d047d5ec377b1835900 > Author: Maarten Lankhorst <maarten.lankhorst@canonical.com> > Date: Tue Jan 21 13:07:31 2014 +0100 > > drm/ttm: kill fence_lock > > No users are left, kill it off! :D > Conversion to the reservation api is next on the list, after > that the functionality can be restored with rcu. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > > CC: stable@vger.kernel.org > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94081 > Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> > --- > drivers/gpu/drm/radeon/radeon_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c > index 00ead8c..89a8c48 100644 > --- a/drivers/gpu/drm/radeon/radeon_display.c > +++ b/drivers/gpu/drm/radeon/radeon_display.c > @@ -573,6 +573,7 @@ vblank_cleanup: > drm_vblank_put(crtc->dev, radeon_crtc->crtc_id); > > pflip_cleanup: > + fence_put(work->fence); > if (unlikely(radeon_bo_reserve(new_rbo, false) != 0)) { > DRM_ERROR("failed to reserve new rbo in error path\n"); > goto cleanup; > @@ -584,7 +585,6 @@ pflip_cleanup: > > cleanup: > drm_gem_object_unreference_unlocked(&work->old_rbo->gem_base); > - fence_put(work->fence); > kfree(work); > return r; > }
Hey,
On 05-03-15 02:13, Jan Vesely wrote:
> please ignore this patch, see bugzilla for details.
Just in case, can you try the patches from https://bugzilla.kernel.org/show_bug.cgi?id=90741 ?
~Maarten
Hi Maarten, sorry for the delay, could not fit tests that freeze the machine into my schedule. I found two patches at that bug. The first one (Use fence_add/remove_callback) is already applied in 4.0. I tried the second one (reshuffle evergreen_dma_fence_ring_emit), but it did not help. However, on the very first attempt the GPU reset worked, so I think it's just a race somewhere, maybe it has always been there and the changes since 3.17 just upset the balance. I'll try to get more details, but the machine occasionally has to run days without reboot so testing kernels can be tricky. regards, Jan On Thu, 2015-03-05 at 11:22 +0100, Maarten Lankhorst wrote: > Hey, > > On 05-03-15 02:13, Jan Vesely wrote: > > please ignore this patch, see bugzilla for details. > Just in case, can you try the patches from https://bugzilla.kernel.org/show_bug.cgi?id=90741 ? > > ~Maarten > >
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 00ead8c..89a8c48 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -573,6 +573,7 @@ vblank_cleanup: drm_vblank_put(crtc->dev, radeon_crtc->crtc_id); pflip_cleanup: + fence_put(work->fence); if (unlikely(radeon_bo_reserve(new_rbo, false) != 0)) { DRM_ERROR("failed to reserve new rbo in error path\n"); goto cleanup; @@ -584,7 +585,6 @@ pflip_cleanup: cleanup: drm_gem_object_unreference_unlocked(&work->old_rbo->gem_base); - fence_put(work->fence); kfree(work); return r; }