On Wed, Dec 21, 2016 at 10:36:41AM +0000, Chris Wilson wrote: > On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote: > > When writing the generic nonblocking commit code I assumed that > > through clever lifetime management I can assure that the completion > > (stored in drm_crtc_commit) only gets freed after it is completed. And > > that worked. > > > > I also wanted to make nonblocking helpers resilient against driver > > bugs, by having timeouts everywhere. And that worked too. > > > > Unfortunately taking boths things together results in oopses :( Well, > > at least sometimes: What seems to happen is that the drm event hangs > > around forever stuck in limbo land. The nonblocking helpers eventually > > time out, move on and release it. Now the bug I tested all this > > against is drivers that just entirely fail to deliver the vblank > > events like they should, and in those cases the event is simply > > leaked. But what seems to happen, at least sometimes, on i915 is that > > the event is set up correctly, but somohow the vblank fails to fire in > > time. Which means the event isn't leaked, it's still there waiting for > > eventually a vblank to fire. That tends to happen when re-enabling the > > pipe, and then the trap springs and the kernel oopses. > > > > The correct fix here is simply to refcount the crtc commit to make > > sure that the event sticks around even for drivers which only > > sometimes fail to deliver vblanks for some arbitrary reasons. Since > > crtc commits are already refcounted that's easy to do. > > Or make the event a part of the atomic state? I guess we could do that, but I wanted the most minimal thing for backporting. And reference-counted atomic state is new, and the patch would be a bit bigger. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html