https://bugzilla.kernel.org/show_bug.cgi?id=94081 --- Comment #4 from Jan Vesely <jan.vesely@xxxxxxxxxxx> --- This does not make sense, the work structure is zeroed so fence put should is OK. it looks like sometimes the lockup needs more than 1 GPU restart to manifest, I'll replay without the good entries (at least it explains inconsistent bisect results) sorry for the noise (In reply to Jan Vesely from comment #3) > (In reply to Michel Dänzer from comment #2) > > Can you bisect? > > It took a while (first bisect found unrelated i915 dispaly commit). > the failure was introduced in: > > commit dd7cfd641228abb2669d8d047d5ec377b1835900 > Author: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> > 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@xxxxxxxxxxxxx> > > the commit moves a call to fence get below two "goto cleanup" in error > paths, however, fence_put is left in the cleanup: error target. Moving the > fence_put call to pflip_cleanup fixes the issue. > > I've posted a patch. > > > > (In reply to Jan Vesely from comment #1) > > > here's dmesg output for 3.17 kernel: > > > > [...] > > > > > [ 249.362280] [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35). > > > [ 249.362281] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB > > > on GFX ring (-35). > > > > Actually, this looks like the reset didn't fully work with 3.17 either > > though... > > I don't remember seeing this during bisection. This log is from fedora > 3.17.8 kernel. I'll check 3.17.8 vanilla and see whether it's fedora specific -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
