Re: [PATCH 1/2] drm: refernce count event->completion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux