Possible fb ref count issue with drm_plane_force_disable()

Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1478 bytes --]

Hi,

I've been debugging omapdrm issues on top of the latest drm mainline
changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
a drm application, or unloading the modules.

The setup is very basic, just a single crtc with the crtc's primary plane.

What seems to happen is:

- App is started

- fb is created, and taken into use by omapdrm. omapdrm takes a ref to
the fb.

- the app is starts to shut down

- drm_framebuffer_remove is called

- fb->refcount.refcount > 1, so it goes to disable stuff

- drm_plane_force_disable is called for the primary plane

- drm_plane_force_disable does plane->disable_plane, which on omapdrm
puts stuff on a workqueue as plane cannot be disabled immediately

- drm_plane_force_disable calls __drm_framebuffer_unreference()

- at the end of drm_framebuffer_remove(), there's
drm_framebuffer_unreference, which causes ref count to go to zero, and
the fb to be destroyed

- a bit later, the queued work is ran, which does
drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm is
removing the ref that had been taken in the beginning.


So the explicit unref done by drm_plane_force_disable() seems a bit out
of place. I can't figure out which drm_framebuffer_reference() would be
the matching one for the unref done by drm_plane_force_disable().

Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
extra in drm_plane_force_disable()?

 Tomi


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Archit Taneja]

Hi,

On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, just a single crtc with the crtc's primary plane.
>
> What seems to happen is:
>
> - App is started
>
> - fb is created, and taken into use by omapdrm. omapdrm takes a ref to
> the fb.
>
> - the app is starts to shut down
>
> - drm_framebuffer_remove is called

Does drm_framebuffer_remove get called when we abort the application, or 
unload omapdrm, or both?

>
> - fb->refcount.refcount > 1, so it goes to disable stuff
>
> - drm_plane_force_disable is called for the primary plane

Maybe we need to make sure that this func is called only when our driver 
has unreferenced it. In that case, we would probably need to flush our 
queue and disable interrupts(so that we don't queue more work).

>
> - drm_plane_force_disable does plane->disable_plane, which on omapdrm
> puts stuff on a workqueue as plane cannot be disabled immediately
>
> - drm_plane_force_disable calls __drm_framebuffer_unreference()
>
> - at the end of drm_framebuffer_remove(), there's
> drm_framebuffer_unreference, which causes ref count to go to zero, and
> the fb to be destroyed
>
> - a bit later, the queued work is ran, which does
> drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm is
> removing the ref that had been taken in the beginning.
>
>
> So the explicit unref done by drm_plane_force_disable() seems a bit out
> of place. I can't figure out which drm_framebuffer_reference() would be
> the matching one for the unref done by drm_plane_force_disable().
>
> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
> extra in drm_plane_force_disable()?


I can't get the corresponding reference for it either. But I can count 3 
of them when you run fbcon with drm's fb helper.

- One ref is taken in the drm_framebuffer_init called from 
omap_fbdev_create.

- fbcon will call fb_set_par, which calls drm_fb_helper_set_par, that 
seems to take a refernce to the fb in the end.

- drm_crtc_helper_set_config() calls the omadrm specific mode_set 
drm_crtc_funcs, which eventually calls a drm_framebuffer_reference in 
update_pin().

Archit

Re: Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 3474 bytes --]

On 11/04/14 09:31, Archit Taneja wrote:
> Hi,
> 
> On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote:
>> Hi,
>>
>> I've been debugging omapdrm issues on top of the latest drm mainline
>> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
>> a drm application, or unloading the modules.
>>
>> The setup is very basic, just a single crtc with the crtc's primary
>> plane.
>>
>> What seems to happen is:
>>
>> - App is started
>>
>> - fb is created, and taken into use by omapdrm. omapdrm takes a ref to
>> the fb.
>>
>> - the app is starts to shut down
>>
>> - drm_framebuffer_remove is called
> 
> Does drm_framebuffer_remove get called when we abort the application, or
> unload omapdrm, or both?

Both. When we abort an app, drm_framebuffer_remove gets called for the
fb that the app created. When we unload omapdrm, it gets called for the
main fb, used for fb console.

>> - fb->refcount.refcount > 1, so it goes to disable stuff
>>
>> - drm_plane_force_disable is called for the primary plane
> 
> Maybe we need to make sure that this func is called only when our driver
> has unreferenced it. In that case, we would probably need to flush our
> queue and disable interrupts(so that we don't queue more work).

Hmm, sorry, call which func, unreferenced what? =)

Do you mean we should call drm_framebuffer_remove() only if
fb->refcount.refcount == 1. That should be possible, and would probably
remove the issue, but it would just be going around the actual problem.

>> - drm_plane_force_disable does plane->disable_plane, which on omapdrm
>> puts stuff on a workqueue as plane cannot be disabled immediately
>>
>> - drm_plane_force_disable calls __drm_framebuffer_unreference()
>>
>> - at the end of drm_framebuffer_remove(), there's
>> drm_framebuffer_unreference, which causes ref count to go to zero, and
>> the fb to be destroyed
>>
>> - a bit later, the queued work is ran, which does
>> drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm is
>> removing the ref that had been taken in the beginning.
>>
>>
>> So the explicit unref done by drm_plane_force_disable() seems a bit out
>> of place. I can't figure out which drm_framebuffer_reference() would be
>> the matching one for the unref done by drm_plane_force_disable().
>>
>> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
>> extra in drm_plane_force_disable()?
> 
> 
> I can't get the corresponding reference for it either. But I can count 3
> of them when you run fbcon with drm's fb helper.
> 
> - One ref is taken in the drm_framebuffer_init called from
> omap_fbdev_create.
> 
> - fbcon will call fb_set_par, which calls drm_fb_helper_set_par, that
> seems to take a refernce to the fb in the end.

This one is not called for a normal app, as there's no fbdev framebuffer
for it. Note that the funcs I mention deal with drm framebuffer, which
is not the fbdev framebuffer (confusing =). fbdev fb is only used for
the "root" framebuffer. And, of course, fbdev fb uses the drm fb
functionality.

> - drm_crtc_helper_set_config() calls the omadrm specific mode_set
> drm_crtc_funcs, which eventually calls a drm_framebuffer_reference in
> update_pin().

Yep.

I forgot to mention that if I comment out the unref in
drm_plane_force_disable(), the ref counts match and all looks fine. And
also that I didn't see this issue with 3.14.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Archit Taneja]

On Friday 11 April 2014 12:10 PM, Tomi Valkeinen wrote:

<snip>

>> Does drm_framebuffer_remove get called when we abort the application, or
>> unload omapdrm, or both?
>
> Both. When we abort an app, drm_framebuffer_remove gets called for the
> fb that the app created. When we unload omapdrm, it gets called for the
> main fb, used for fb console.
>
>>> - fb->refcount.refcount > 1, so it goes to disable stuff
>>>
>>> - drm_plane_force_disable is called for the primary plane
>>
>> Maybe we need to make sure that this func is called only when our driver
>> has unreferenced it. In that case, we would probably need to flush our
>> queue and disable interrupts(so that we don't queue more work).
>
> Hmm, sorry, call which func, unreferenced what? =)
>
> Do you mean we should call drm_framebuffer_remove() only if
> fb->refcount.refcount == 1. That should be possible, and would probably
> remove the issue, but it would just be going around the actual problem.

Yes, I meant our driver should call drm_framebuffer_remove() only when 
we are know that the fb reference omapdrm had taken(the one in 
update_pin), has a corresponding fb unref called(in unpin_worker).

Isn't that something omapdrm should take care of?

<snip>

>> I can't get the corresponding reference for it either. But I can count 3
>> of them when you run fbcon with drm's fb helper.
>>
>> - One ref is taken in the drm_framebuffer_init called from
>> omap_fbdev_create.
>>
>> - fbcon will call fb_set_par, which calls drm_fb_helper_set_par, that
>> seems to take a refernce to the fb in the end.
>
> This one is not called for a normal app, as there's no fbdev framebuffer
> for it. Note that the funcs I mention deal with drm framebuffer, which
> is not the fbdev framebuffer (confusing =). fbdev fb is only used for
> the "root" framebuffer. And, of course, fbdev fb uses the drm fb

Yes. In the case of a normal app, we would call the ADD_FB2 ioctl to get 
a drm_framebuffer, that will internally take a fb reference. So the 
count won't seem to go beyond 2.

> functionality.
>
>> - drm_crtc_helper_set_config() calls the omadrm specific mode_set
>> drm_crtc_funcs, which eventually calls a drm_framebuffer_reference in
>> update_pin().
>
> Yep.
>
> I forgot to mention that if I comment out the unref in
> drm_plane_force_disable(), the ref counts match and all looks fine. And
> also that I didn't see this issue with 3.14.

That's strange. I guess there must be an extra unref happening somewhere 
in the newer commits. Did you try a diff of drm code between the 2 
kernels? :)

Archit

Re: Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1353 bytes --]

On 11/04/14 09:57, Archit Taneja wrote:

> Yes, I meant our driver should call drm_framebuffer_remove() only when
> we are know that the fb reference omapdrm had taken(the one in
> update_pin), has a corresponding fb unref called(in unpin_worker).
> 
> Isn't that something omapdrm should take care of?

Yes, we could do it, and it's probably something we should do. I haven't
looked at it, so I don't know how easy or difficult it is to make sure
the fb won't be used after we think it has been disabled.

But even so, the drm_framebuffer_remove() seems to be designed to handle
the case where the fb is still in use, but it's failing.

>> I forgot to mention that if I comment out the unref in
>> drm_plane_force_disable(), the ref counts match and all looks fine. And
>> also that I didn't see this issue with 3.14.
> 
> That's strange. I guess there must be an extra unref happening somewhere
> in the newer commits. Did you try a diff of drm code between the 2
> kernels? :)

Not yet. I'm guessing that it's about the plane changes. There was
already one issue with omapdrm, where the crtc calls plane->destroy on
the crtc's primary plane. With the latest changes, the all the planes,
including the primary planes, are destroyed automatically, so the crtc's
destroy call is not needed (and causes a crash).

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Daniel Vetter]

On Thu, Apr 10, 2014 at 02:47:52PM +0300, Tomi Valkeinen wrote:
> Hi,
> 
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
> 
> The setup is very basic, just a single crtc with the crtc's primary plane.
> 
> What seems to happen is:
> 
> - App is started
> 
> - fb is created, and taken into use by omapdrm. omapdrm takes a ref to
> the fb.
> 
> - the app is starts to shut down
> 
> - drm_framebuffer_remove is called
> 
> - fb->refcount.refcount > 1, so it goes to disable stuff
> 
> - drm_plane_force_disable is called for the primary plane
> 
> - drm_plane_force_disable does plane->disable_plane, which on omapdrm
> puts stuff on a workqueue as plane cannot be disabled immediately
> 
> - drm_plane_force_disable calls __drm_framebuffer_unreference()
> 
> - at the end of drm_framebuffer_remove(), there's
> drm_framebuffer_unreference, which causes ref count to go to zero, and
> the fb to be destroyed
> 
> - a bit later, the queued work is ran, which does
> drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm is
> removing the ref that had been taken in the beginning.
> 
> 
> So the explicit unref done by drm_plane_force_disable() seems a bit out
> of place. I can't figure out which drm_framebuffer_reference() would be
> the matching one for the unref done by drm_plane_force_disable().
> 
> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
> extra in drm_plane_force_disable()?

plane->fb is holding a reference which should have been acquired in
drm_mode_setplane. It's not really explicit since drm_framebuffer_lookup
implicitly grabs a ref for you.

Hence when we disable the plane and set plane->fb = NULL we must drop that
ref again. So that's not the bug, but clearly something goes wrong
somewhere.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: Possible fb ref count issue with drm_plane_force_disable()

[Ville Syrjälä]

On Thu, Apr 10, 2014 at 02:47:52PM +0300, Tomi Valkeinen wrote:
> Hi,
> 
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
> 
> The setup is very basic, just a single crtc with the crtc's primary plane.
> 
> What seems to happen is:
> 
> - App is started
> 
> - fb is created, and taken into use by omapdrm. omapdrm takes a ref to
> the fb.
> 
> - the app is starts to shut down
> 
> - drm_framebuffer_remove is called
> 
> - fb->refcount.refcount > 1, so it goes to disable stuff
> 
> - drm_plane_force_disable is called for the primary plane
> 
> - drm_plane_force_disable does plane->disable_plane, which on omapdrm
> puts stuff on a workqueue as plane cannot be disabled immediately
> 
> - drm_plane_force_disable calls __drm_framebuffer_unreference()
> 
> - at the end of drm_framebuffer_remove(), there's
> drm_framebuffer_unreference, which causes ref count to go to zero, and
> the fb to be destroyed
> 
> - a bit later, the queued work is ran, which does
> drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm is
> removing the ref that had been taken in the beginning.
> 
> 
> So the explicit unref done by drm_plane_force_disable() seems a bit out
> of place. I can't figure out which drm_framebuffer_reference() would be
> the matching one for the unref done by drm_plane_force_disable().
> 
> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
> extra in drm_plane_force_disable()?

That's the reference that was taken by the drm_mode_setplane() when it
succesfully called the .update_plane() hook.

__drm_framebuffer_unregister() drops the "idr reference" taken in
drm_framebuffer_init().

And the last ref dropped by drm_framebuffer_remove() is the initial ref
from kref_init() which I suppose is what the 'fpriv->fbs reference'
comments are referring to.
 
-- 
Ville Syrjälä
Intel OTC

Re: Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

[-- Attachment #1.1.1: Type: text/plain, Size: 1563 bytes --]

On 11/04/14 14:50, Ville Syrjälä wrote:

>> So the explicit unref done by drm_plane_force_disable() seems a bit out
>> of place. I can't figure out which drm_framebuffer_reference() would be
>> the matching one for the unref done by drm_plane_force_disable().
>>
>> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
>> extra in drm_plane_force_disable()?
> 
> That's the reference that was taken by the drm_mode_setplane() when it
> succesfully called the .update_plane() hook.

But drm_mode_setplane() is called via DRM_IOCTL_MODE_SETPLANE, which is
only used for "proper" planes, not for crtc primary planes, right?

At least I don't see drm_mode_setplane() in my stack traces, and git
grep doesn't show it called via any other means than ioctl.

I am not using any planes from my app, just the crtc and (indirectly)
its primary plane.

I've attached a slightly cleaned up log when running my test app. I have
dump_stack()s in the drm_framebuffer_(un)reference functions, and a
printk just before the dump_stack which prints something like "REF FB
ID: 36: 2", where 36 is the fb id, and 2 is the ref count after the
ref/unref.

In the middle of the log there are multiple blank lines, that's where I
ctrl-c the app and it starts shutting down. FB ID 35 is probably the
fbconsole fb, and 36 is the app's fb. And at some point the FB ID 36
changes to 0, as the drm framework clears it.

> __drm_framebuffer_unregister() drops the "idr reference" taken in
> drm_framebuffer_init().

What's "idr"?

 Tomi


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: m.log --]
[-- Type: text/x-log; name="m.log", Size: 23613 bytes --]

# ./nfs/work/omapdrm-tests/perf
using card '/dev/dri/card0'
mode for connector 5 is 1920x1200
1920x1200, stride 7680, size 9216000
[ 3145.642944] REF FB ID: 36: 2
[ 3145.649841] CPU: 0 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3145.661102] Backtrace: 
[ 3145.663726] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3145.672058] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3145.685607] [<c05b8028>] (dump_stack) from [<bf1cc90c>] (drm_framebuffer_reference+0x54/0x98 [drm])
[ 3145.695251] [<bf1cc8b8>] (drm_framebuffer_reference [drm]) from [<bf1ce0ac>] (drm_framebuffer_init+0x64/0x94 [drm])
[ 3145.714233] [<bf1ce048>] (drm_framebuffer_init [drm]) from [<bf233614>] (omap_framebuffer_init+0x1ec/0x2b0 [omapdrm])
[ 3145.729888] [<bf233428>] (omap_framebuffer_init [omapdrm]) from [<bf2337c0>] (omap_framebuffer_create+0xe8/0x210 [omapdrm])
[ 3145.754577] [<bf2336d8>] (omap_framebuffer_create [omapdrm]) from [<bf1d0f24>] (drm_mode_addfb2+0x6b8/0x88c [drm])
[ 3145.776672] [<bf1d086c>] (drm_mode_addfb2 [drm]) from [<bf1c313c>] (drm_ioctl+0x198/0x508 [drm])
[ 3145.797180] [<bf1c2fa4>] (drm_ioctl [drm]) from [<c013b544>] (do_vfs_ioctl+0x80/0x628)
[ 3145.810394] [<c013b4c4>] (do_vfs_ioctl) from [<c013bb58>] (SyS_ioctl+0x6c/0x7c)
[ 3145.829864] [<c013baec>] (SyS_ioctl) from [<c000f580>] (ret_fast_syscall+0x0/0x48)
[ 3145.851776] ===========================
[ 3145.851776] 
ignoring unused connector 12
[ 3145.952850] REF FB ID: 36: 3
[ 3145.953002] CPU: 0 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3145.967956] Backtrace: 
[ 3145.970367] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3145.983367] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3145.992370] [<c05b8028>] (dump_stack) from [<bf1cc90c>] (drm_framebuffer_reference+0x54/0x98 [drm])
[ 3146.002105] [<bf1cc8b8>] (drm_framebuffer_reference [drm]) from [<bf1ccb98>] (drm_framebuffer_lookup+0x3c/0x4c [drm])
[ 3146.017639] [<bf1ccb5c>] (drm_framebuffer_lookup [drm]) from [<bf1d027c>] (drm_mode_setcrtc+0xf0/0x4f4 [drm])
[ 3146.032196] [<bf1d018c>] (drm_mode_setcrtc [drm]) from [<bf1c313c>] (drm_ioctl+0x198/0x508 [drm])
[ 3146.056213] [<bf1c2fa4>] (drm_ioctl [drm]) from [<c013b544>] (do_vfs_ioctl+0x80/0x628)
[ 3146.075378] [<c013b4c4>] (do_vfs_ioctl) from [<c013bb58>] (SyS_ioctl+0x6c/0x7c)
[ 3146.096649] [<c013baec>] (SyS_ioctl) from [<c000f580>] (ret_fast_syscall+0x0/0x48)
[ 3146.105285] ===========================
[ 3146.105285] 
[ 3146.119659] REF FB ID: 36: 4
[ 3146.122772] CPU: 0 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3146.132232] Backtrace: 
[ 3146.132232] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3146.143157] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3146.156524] [<c05b8028>] (dump_stack) from [<bf1cc90c>] (drm_framebuffer_reference+0x54/0x98 [drm])
[ 3146.157073] [<bf1cc8b8>] (drm_framebuffer_reference [drm]) from [<bf1cca68>] (drm_mode_set_config_internal+0xa8/0xf0 [drm])
[ 3146.182342] [<bf1cc9c0>] (drm_mode_set_config_internal [drm]) from [<bf1d0258>] (drm_mode_setcrtc+0xcc/0x4f4 [drm])
[ 3146.200714] [<bf1d018c>] (drm_mode_setcrtc [drm]) from [<bf1c313c>] (drm_ioctl+0x198/0x508 [drm])
[ 3146.223815] [<bf1c2fa4>] (drm_ioctl [drm]) from [<c013b544>] (do_vfs_ioctl+0x80/0x628)
[ 3146.240539] [<c013b4c4>] (do_vfs_ioctl) from [<c013bb58>] (SyS_ioctl+0x6c/0x7c)
[ 3146.259918] [<c013baec>] (SyS_ioctl) from [<c000f580>] (ret_fast_syscall+0x0/0x48)
[ 3146.278350] ===========================
[ 3146.278350] 
[ 3146.283996] UNREF FB ID: 35: 3
[ 3146.284454] CPU: 0 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3146.296722] Backtrace: 
[ 3146.296905] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3146.309875] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3146.319763] [<c05b8028>] (dump_stack) from [<bf1cc978>] (drm_framebuffer_unreference+0x28/0x70 [drm])
[ 3146.334899] [<bf1cc950>] (drm_framebuffer_unreference [drm]) from [<bf1cca78>] (drm_mode_set_config_internal+0xb8/0xf0 [drm])
[ 3146.347167] [<bf1cc9c0>] (drm_mode_set_config_internal [drm]) from [<bf1d0258>] (drm_mode_setcrtc+0xcc/0x4f4 [drm])
[ 3146.362243] [<bf1d018c>] (drm_mode_setcrtc [drm]) from [<bf1c313c>] (drm_ioctl+0x198/0x508 [drm])
[ 3146.381774] [<bf1c2fa4>] (drm_ioctl [drm]) from [<c013b544>] (do_vfs_ioctl+0x80/0x628)
[ 3146.402191] [<c013b4c4>] (do_vfs_ioctl) from [<c013bb58>] (SyS_ioctl+0x6c/0x7c)
[ 3146.420684] [<c013baec>] (SyS_ioctl) from [<c000f580>] (ret_fast_syscall+0x0/0x48)
[ 3146.439788] ===========================
[ 3146.439788] 
[ 3146.448791] UNREF FB ID: 36: 3
[ 3146.452056] CPU: 0 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3146.461547] Backtrace: 
[ 3146.464172] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3146.472930] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3146.485992] [<c05b8028>] (dump_stack) from [<bf1cc978>] (drm_framebuffer_unreference+0x28/0x70 [drm])
[ 3146.499755] [<bf1cc950>] (drm_framebuffer_unreference [drm]) from [<bf1d03d0>] (drm_mode_setcrtc+0x244/0x4f4 [drm])
[ 3146.511077] [<bf1d018c>] (drm_mode_setcrtc [drm]) from [<bf1c313c>] (drm_ioctl+0x198/0x508 [drm])
[ 3146.535278] [<bf1c2fa4>] (drm_ioctl [drm]) from [<c013b544>] (do_vfs_ioctl+0x80/0x628)
[ 3146.550720] [<c013b4c4>] (do_vfs_ioctl) from [<c013bb58>] (SyS_ioctl+0x6c/0x7c)
[ 3146.573486] [<c013baec>] (SyS_ioctl) from [<c000f580>] (ret_fast_syscall+0x0/0x48)
[ 3146.589904] ===========================
[ 3146.589904] 
sequential_line_read: [ 3146.627410] UPDATE PIN REF
[ 3146.630371] REF FB ID: 36: 4
[ 3146.630584] CPU: 1 PID: 1519 Comm: kworker/u4:0 Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3146.643646] Workqueue: omapdrm apply_worker [omapdrm]
[ 3146.643646] Backtrace: 
[ 3146.651733] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3146.663604] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3146.663604] [<c05b8028>] (dump_stack) from [<bf1cc90c>] (drm_framebuffer_reference+0x54/0x98 [drm])
[ 3146.683563] [<bf1cc8b8>] (drm_framebuffer_reference [drm]) from [<bf231c44>] (omap_plane_pre_apply+0x188/0x248 [omapdrm])
[ 3146.702331] [<bf231abc>] (omap_plane_pre_apply [omapdrm]) from [<bf2310b8>] (apply_worker+0xb0/0x178 [omapdrm])
[ 3146.721527] [<bf231008>] (apply_worker [omapdrm]) from [<c005e8f0>] (process_one_work+0x1b8/0x510)
[ 3146.740753] [<c005e738>] (process_one_work) from [<c005f050>] (worker_thread+0x120/0x394)
[ 3146.764434] [<c005ef30>] (worker_thread) from [<c0065e9c>] (kthread+0xd0/0xec)
[ 3146.783142] [<c0065dcc>] (kthread) from [<c000f648>] (ret_from_fork+0x14/0x2c)
[ 3146.795562] ===========================
[ 3146.795562] 
[ 3146.810913] sleep
[ 3148.320739] sleep done
[ 3148.320739] UNPIN WORKER UNREF
[ 3148.320739] UNREF FB ID: 35: 2
[ 3148.329681] CPU: 1 PID: 1519 Comm: kworker/u4:0 Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3148.340087] Workqueue: omapdrm flip_worker [drm]
[ 3148.340087] Backtrace: 
[ 3148.340087] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3148.361633] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3148.369354] [<c05b8028>] (dump_stack) from [<bf1cc978>] (drm_framebuffer_unreference+0x28/0x70 [drm])
[ 3148.381744] [<bf1cc950>] (drm_framebuffer_unreference [drm]) from [<bf231d58>] (unpin_worker+0x54/0x70 [omapdrm])
[ 3148.396453] [<bf231d04>] (unpin_worker [omapdrm]) from [<bf1da5bc>] (flip_worker+0x94/0xa0 [drm])
[ 3148.410858] [<bf1da528>] (flip_worker [drm]) from [<c005e8f0>] (process_one_work+0x1b8/0x510)
[ 3148.427215] [<c005e738>] (process_one_work) from [<c005f050>] (worker_thread+0x120/0x394)
[ 3148.445404] [<c005ef30>] (worker_thread) from [<c0065e9c>] (kthread+0xd0/0xec)
[ 3148.466766] [<c0065dcc>] (kthread) from [<c000f648>] (ret_from_fork+0x14/0x2c)
[ 3148.480407] ===========================
[ 3148.480407] 



72 frames, 3164001 us, 22 fps
sequential_line_write: 









\x03[ 3152.279907] __UNREF FB ID: 0: 3
[ 3152.283325] CPU: 1 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3152.292846] Backtrace: 
[ 3152.293182] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3152.306427] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3152.317199] [<c05b8028>] (dump_stack) from [<bf1cc7ec>] (__drm_framebuffer_unreference+0x28/0x6c [drm])
[ 3152.329895] [<bf1cc7c4>] (__drm_framebuffer_unreference [drm]) from [<bf1cc878>] (__drm_framebuffer_unregister+0x48/0x4c [drm])
[ 3152.347564] [<bf1cc830>] (__drm_framebuffer_unregister [drm]) from [<bf1d14a4>] (drm_fb_release+0x60/0xa4 [drm])
[ 3152.360870] [<bf1d1444>] (drm_fb_release [drm]) from [<bf1c4298>] (drm_release+0x494/0x544 [drm])
[ 3152.379943] [<bf1c3e04>] (drm_release [drm]) from [<c012b828>] (__fput+0x9c/0x1ec)
[ 3152.400238] [<c012b78c>] (__fput) from [<c012b9d8>] (____fput+0x10/0x14)
[ 3152.421020] [<c012b9c8>] (____fput) from [<c0062c80>] (task_work_run+0xbc/0x100)
[ 3152.431365] [<c0062bc4>] (task_work_run) from [<c00473d0>] (do_exit+0x2f8/0x950)
[ 3152.441772] [<c00470d8>] (do_exit) from [<c0047b3c>] (do_group_exit+0x44/0xb8)
[ 3152.457855] [<c0047af8>] (do_group_exit) from [<c0055d04>] (get_signal_to_deliver+0x23c/0x67c)
[ 3152.472320] [<c0055ac8>] (get_signal_to_deliver) from [<c05b4504>] (do_signal+0xb4/0x3d8)
[ 3152.490112] [<c05b4450>] (do_signal) from [<c0012588>] (do_work_pending+0xa4/0xe4)
[ 3152.501098] [<c00124e4>] (do_work_pending) from [<c000f5d8>] (work_pending+0xc/0x20)
[ 3152.525726] ===========================
[ 3152.525726] 
[ 3152.531799] UNREF FB ID: 0: 2
[ 3152.532073] CPU: 1 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3152.544464] Backtrace: 
[ 3152.544647] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3152.560943] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3152.564147] [<c05b8028>] (dump_stack) from [<bf1cc978>] (drm_framebuffer_unreference+0x28/0x70 [drm])
[ 3152.581207] [<bf1cc950>] (drm_framebuffer_unreference [drm]) from [<bf1cca78>] (drm_mode_set_config_internal+0xb8/0xf0 [drm])
[ 3152.595062] [<bf1cc9c0>] (drm_mode_set_config_internal [drm]) from [<bf1cd0f4>] (drm_framebuffer_remove+0x10c/0x14c [drm])
[ 3152.610778] [<bf1ccfe8>] (drm_framebuffer_remove [drm]) from [<bf1d14c8>] (drm_fb_release+0x84/0xa4 [drm])
[ 3152.633911] [<bf1d1444>] (drm_fb_release [drm]) from [<bf1c4298>] (drm_release+0x494/0x544 [drm])
[ 3152.650756] [<bf1c3e04>] (drm_release [drm]) from [<c012b828>] (__fput+0x9c/0x1ec)
[ 3152.669921] [<c012b78c>] (__fput) from [<c012b9d8>] (____fput+0x10/0x14)
[ 3152.690704] [<c012b9c8>] (____fput) from [<c0062c80>] (task_work_run+0xbc/0x100)
[ 3152.701080] [<c0062bc4>] (task_work_run) from [<c00473d0>] (do_exit+0x2f8/0x950)
[ 3152.711456] [<c00470d8>] (do_exit) from [<c0047b3c>] (do_group_exit+0x44/0xb8)
[ 3152.725189] [<c0047af8>] (do_group_exit) from [<c0055d04>] (get_signal_to_deliver+0x23c/0x67c)
[ 3152.740295] [<c0055ac8>] (get_signal_to_deliver) from [<c05b4504>] (do_signal+0xb4/0x3d8)
[ 3152.762481] [<c05b4450>] (do_signal) from [<c0012588>] (do_work_pending+0xa4/0xe4)
[ 3152.776824] [<c00124e4>] (do_work_pending) from [<c000f5d8>] (work_pending+0xc/0x20)
[ 3152.792205] ===========================
[ 3152.792205] 
[ 3152.899841] 
[ 3152.899841] 
[ 3152.899841] ====
[ 3152.899841] ABOUT TO FORCE DISABLE PLANE
[ 3152.909057] __UNREF FB ID: 0: 1
[ 3152.912384] CPU: 1 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3152.921905] Backtrace: 
[ 3152.922821] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3152.938568] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3152.938568] [<c05b8028>] (dump_stack) from [<bf1cc7ec>] (__drm_framebuffer_unreference+0x28/0x6c [drm])
[ 3152.959930] [<bf1cc7c4>] (__drm_framebuffer_unreference [drm]) from [<bf1cce1c>] (drm_plane_force_disable+0x38/0x60 [drm])
[ 3152.972442] [<bf1ccde4>] (drm_plane_force_disable [drm]) from [<bf1cd118>] (drm_framebuffer_remove+0x130/0x14c [drm])
[ 3152.991302] [<bf1ccfe8>] (drm_framebuffer_remove [drm]) from [<bf1d14c8>] (drm_fb_release+0x84/0xa4 [drm])
[ 3153.002197] [<bf1d1444>] (drm_fb_release [drm]) from [<bf1c4298>] (drm_release+0x494/0x544 [drm])
[ 3153.030517] [<bf1c3e04>] (drm_release [drm]) from [<c012b828>] (__fput+0x9c/0x1ec)
[ 3153.041168] [<c012b78c>] (__fput) from [<c012b9d8>] (____fput+0x10/0x14)
[ 3153.067687] [<c012b9c8>] (____fput) from [<c0062c80>] (task_work_run+0xbc/0x100)
[ 3153.075622] [<c0062bc4>] (task_work_run) from [<c00473d0>] (do_exit+0x2f8/0x950)
[ 3153.083526] [<c00470d8>] (do_exit) from [<c0047b3c>] (do_group_exit+0x44/0xb8)
[ 3153.099365] [<c0047af8>] (do_group_exit) from [<c0055d04>] (get_signal_to_deliver+0x23c/0x67c)
[ 3153.111846] [<c0055ac8>] (get_signal_to_deliver) from [<c05b4504>] (do_signal+0xb4/0x3d8)
[ 3153.134246] [<c05b4450>] (do_signal) from [<c0012588>] (do_work_pending+0xa4/0xe4)
[ 3153.149810] [<c00124e4>] (do_work_pending) from [<c000f5d8>] (work_pending+0xc/0x20)
[ 3153.161926] ===========================
[ 3153.161926] 
[ 3153.269805] 
[ 3153.269805] 
[ 3153.269805] ====
[ 3153.269805] FORCE DISABLE PLANE done
[ 3153.269805] 
[ 3153.280273] UNREF FB ID: 0: 0
[ 3153.283264] CPU: 1 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3153.283477] sleep
[ 3153.294921] Backtrace: 
[ 3153.296264] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3153.311645] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3153.319305] [<c05b8028>] (dump_stack) from [<bf1cc978>] (drm_framebuffer_unreference+0x28/0x70 [drm])
[ 3153.331756] [<bf1cc950>] (drm_framebuffer_unreference [drm]) from [<bf1cd024>] (drm_framebuffer_remove+0x3c/0x14c [drm])
[ 3153.345153] [<bf1ccfe8>] (drm_framebuffer_remove [drm]) from [<bf1d14c8>] (drm_fb_release+0x84/0xa4 [drm])
[ 3153.361572] [<bf1d1444>] (drm_fb_release [drm]) from [<bf1c4298>] (drm_release+0x494/0x544 [drm])
[ 3153.384216] [<bf1c3e04>] (drm_release [drm]) from [<c012b828>] (__fput+0x9c/0x1ec)
[ 3153.405364] [<c012b78c>] (__fput) from [<c012b9d8>] (____fput+0x10/0x14)
[ 3153.424804] [<c012b9c8>] (____fput) from [<c0062c80>] (task_work_run+0xbc/0x100)
[ 3153.433227] [<c0062bc4>] (task_work_run) from [<c00473d0>] (do_exit+0x2f8/0x950)
[ 3153.445343] [<c00470d8>] (do_exit) from [<c0047b3c>] (do_group_exit+0x44/0xb8)
[ 3153.457336] [<c0047af8>] (do_group_exit) from [<c0055d04>] (get_signal_to_deliver+0x23c/0x67c)
[ 3153.471343] [<c0055ac8>] (get_signal_to_deliver) from [<c05b4504>] (do_signal+0xb4/0x3d8)
[ 3153.491394] [<c05b4450>] (do_signal) from [<c0012588>] (do_work_pending+0xa4/0xe4)
[ 3153.509094] [<c00124e4>] (do_work_pending) from [<c000f5d8>] (work_pending+0xc/0x20)
[ 3153.521850] ===========================
[ 3153.521850] 
[ 3153.533233] destroy: FB ID: 0 (eb48f7c0)
[ 3153.569152] REF FB ID: 35: 3
[ 3153.572265] CPU: 1 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3153.572631] Backtrace: 
[ 3153.581756] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3153.592742] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3153.606231] [<c05b8028>] (dump_stack) from [<bf1cc90c>] (drm_framebuffer_reference+0x54/0x98 [drm])
[ 3153.619781] [<bf1cc8b8>] (drm_framebuffer_reference [drm]) from [<bf1cca68>] (drm_mode_set_config_internal+0xa8/0xf0 [drm])
[ 3153.631988] [<bf1cc9c0>] (drm_mode_set_config_internal [drm]) from [<bf220a70>] (drm_fb_helper_restore_fbdev_mode+0xb8/0xd8 [drm_kms_helper])
[ 3153.651550] [<bf2209b8>] (drm_fb_helper_restore_fbdev_mode [drm_kms_helper]) from [<bf22f588>] (dev_lastclose+0xc4/0x118 [omapdrm])
[ 3153.670196] [<bf22f4c4>] (dev_lastclose [omapdrm]) from [<bf1c3cfc>] (drm_lastclose+0x38/0x140 [drm])
[ 3153.693176] [<bf1c3cc4>] (drm_lastclose [drm]) from [<bf1c4148>] (drm_release+0x344/0x544 [drm])
[ 3153.710845] [<bf1c3e04>] (drm_release [drm]) from [<c012b828>] (__fput+0x9c/0x1ec)
[ 3153.730041] [<c012b78c>] (__fput) from [<c012b9d8>] (____fput+0x10/0x14)
[ 3153.742401] [<c012b9c8>] (____fput) from [<c0062c80>] (task_work_run+0xbc/0x100)
[ 3153.756072] [<c0062bc4>] (task_work_run) from [<c00473d0>] (do_exit+0x2f8/0x950)
[ 3153.770874] [<c00470d8>] (do_exit) from [<c0047b3c>] (do_group_exit+0x44/0xb8)
[ 3153.780212] [<c0047af8>] (do_group_exit) from [<c0055d04>] (get_signal_to_deliver+0x23c/0x67c)
[ 3153.797729] [<c0055ac8>] (get_signal_to_deliver) from [<c05b4504>] (do_signal+0xb4/0x3d8)
[ 3153.817443] [<c05b4450>] (do_signal) from [<c0012588>] (do_work_pending+0xa4/0xe4)
[ 3153.833770] [<c00124e4>] (do_work_pending) from [<c000f5d8>] (work_pending+0xc/0x20)
[ 3153.850372] ===========================
[ 3153.850372] 
[ 3153.850860] REF FB ID: 35: 4
[ 3153.857086] CPU: 1 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3153.868530] Backtrace: 
[ 3153.871185] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3153.883178] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3153.888397] [<c05b8028>] (dump_stack) from [<bf1cc90c>] (drm_framebuffer_reference+0x54/0x98 [drm])
[ 3153.903076] [<bf1cc8b8>] (drm_framebuffer_reference [drm]) from [<bf1cca68>] (drm_mode_set_config_internal+0xa8/0xf0 [drm])
[ 3153.920898] [<bf1cc9c0>] (drm_mode_set_config_internal [drm]) from [<bf220a70>] (drm_fb_helper_restore_fbdev_mode+0xb8/0xd8 [drm_kms_helper])
[ 3153.941162] [<bf2209b8>] (drm_fb_helper_restore_fbdev_mode [drm_kms_helper]) from [<bf22f588>] (dev_lastclose+0xc4/0x118 [omapdrm])
[ 3153.961547] [<bf22f4c4>] (dev_lastclose [omapdrm]) from [<bf1c3cfc>] (drm_lastclose+0x38/0x140 [drm])
[ 3153.979766] [<bf1c3cc4>] (drm_lastclose [drm]) from [<bf1c4148>] (drm_release+0x344/0x544 [drm])
[ 3153.991699] [<bf1c3e04>] (drm_release [drm]) from [<c012b828>] (__fput+0x9c/0x1ec)
[ 3154.013763] [<c012b78c>] (__fput) from [<c012b9d8>] (____fput+0x10/0x14)
[ 3154.030792] [<c012b9c8>] (____fput) from [<c0062c80>] (task_work_run+0xbc/0x100)
[ 3154.042633] [<c0062bc4>] (task_work_run) from [<c00473d0>] (do_exit+0x2f8/0x950)
[ 3154.058715] [<c00470d8>] (do_exit) from [<c0047b3c>] (do_group_exit+0x44/0xb8)
[ 3154.066741] [<c0047af8>] (do_group_exit) from [<c0055d04>] (get_signal_to_deliver+0x23c/0x67c)
[ 3154.080718] [<c0055ac8>] (get_signal_to_deliver) from [<c05b4504>] (do_signal+0xb4/0x3d8)
[ 3154.101531] [<c05b4450>] (do_signal) from [<c0012588>] (do_work_pending+0xa4/0xe4)
[ 3154.120391] [<c00124e4>] (do_work_pending) from [<c000f5d8>] (work_pending+0xc/0x20)
[ 3154.136962] ===========================
[ 3154.136962] 
[ 3154.142608] UNREF FB ID: 35: 3
[ 3154.143157] CPU: 1 PID: 1525 Comm: perf Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3154.155334] Backtrace: 
[ 3154.156463] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3154.170715] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3154.179748] [<c05b8028>] (dump_stack) from [<bf1cc978>] (drm_framebuffer_unreference+0x28/0x70 [drm])
[ 3154.193572] [<bf1cc950>] (drm_framebuffer_unreference [drm]) from [<bf1cca78>] (drm_mode_set_config_internal+0xb8/0xf0 [drm])
[ 3154.209472] [<bf1cc9c0>] (drm_mode_set_config_internal [drm]) from [<bf220a70>] (drm_fb_helper_restore_fbdev_mode+0xb8/0xd8 [drm_kms_helper])
[ 3154.229003] [<bf2209b8>] (drm_fb_helper_restore_fbdev_mode [drm_kms_helper]) from [<bf22f588>] (dev_lastclose+0xc4/0x118 [omapdrm])
[ 3154.241882] [<bf22f4c4>] (dev_lastclose [omapdrm]) from [<bf1c3cfc>] (drm_lastclose+0x38/0x140 [drm])
[ 3154.266967] [<bf1c3cc4>] (drm_lastclose [drm]) from [<bf1c4148>] (drm_release+0x344/0x544 [drm])
[ 3154.279907] [<bf1c3e04>] (drm_release [drm]) from [<c012b828>] (__fput+0x9c/0x1ec)
[ 3154.301147] [<c012b78c>] (__fput) from [<c012b9d8>] (____fput+0x10/0x14)
[ 3154.321929] [<c012b9c8>] (____fput) from [<c0062c80>] (task_work_run+0xbc/0x100)
[ 3154.329864] [<c0062bc4>] (task_work_run) from [<c00473d0>] (do_exit+0x2f8/0x950)
[ 3154.345947] [<c00470d8>] (do_exit) from [<c0047b3c>] (do_group_exit+0x44/0xb8)
[ 3154.353973] [<c0047af8>] (do_group_exit) from [<c0055d04>] (get_signal_to_deliver+0x23c/0x67c)
[ 3154.370178] [<c0055ac8>] (get_signal_to_deliver) from [<c05b4504>] (do_signal+0xb4/0x3d8)
[ 3154.391204] [<c05b4450>] (do_signal) from [<c0012588>] (do_work_pending+0xa4/0xe4)
[ 3154.401855] [<c00124e4>] (do_work_pending) from [<c000f5d8>] (work_pending+0xc/0x20)
[ 3154.420623] ===========================
[ 3154.420623] 

[ 3154.789916] sleep done
[ 3154.789947] UNPIN WORKER UNREF
[ 3154.795654] UNREF FB ID: 0: -1
[ 3154.798889] CPU: 0 PID: 1519 Comm: kworker/u4:0 Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3154.798889] Workqueue: omapdrm flip_worker [drm]
[ 3154.814208] Backtrace: 
[ 3154.816833] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3154.830718] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3154.830718] [<c05b8028>] (dump_stack) from [<bf1cc978>] (drm_framebuffer_unreference+0x28/0x70 [drm])
[ 3154.852355] [<bf1cc950>] (drm_framebuffer_unreference [drm]) from [<bf231d58>] (unpin_worker+0x54/0x70 [omapdrm])
[ 3154.863800] [<bf231d04>] (unpin_worker [omapdrm]) from [<bf1da5bc>] (flip_worker+0x94/0xa0 [drm])
[ 3154.863800] [<bf1da528>] (flip_worker [drm]) from [<c005e8f0>] (process_one_work+0x1b8/0x510)
[ 3154.897033] [<c005e738>] (process_one_work) from [<c005f050>] (worker_thread+0x120/0x394)
[ 3154.914855] [<c005ef30>] (worker_thread) from [<c0065e9c>] (kthread+0xd0/0xec)
[ 3154.933563] [<c0065dcc>] (kthread) from [<c000f648>] (ret_from_fork+0x14/0x2c)
[ 3154.949951] ===========================
[ 3154.949951] 
[ 3154.955718] UPDATE PIN REF
[ 3154.958618] REF FB ID: 35: 4
[ 3154.961730] CPU: 0 PID: 1519 Comm: kworker/u4:0 Tainted: G        W     3.15.0-rc1-00033-g16787b3dfc0f #45
[ 3154.971984] Workqueue: omapdrm apply_worker [omapdrm]
[ 3154.972015] Backtrace: 
[ 3154.972015] [<c0012bfc>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
[ 3154.994049] [<c0012d80>] (show_stack) from [<c05b80bc>] (dump_stack+0x94/0xc8)
[ 3155.001770] [<c05b8028>] (dump_stack) from [<bf1cc90c>] (drm_framebuffer_reference+0x54/0x98 [drm])
[ 3155.015472] [<bf1cc8b8>] (drm_framebuffer_reference [drm]) from [<bf231c44>] (omap_plane_pre_apply+0x188/0x248 [omapdrm])
[ 3155.015472] [<bf231abc>] (omap_plane_pre_apply [omapdrm]) from [<bf2310b8>] (apply_worker+0xb0/0x178 [omapdrm])
[ 3155.042053] [<bf231008>] (apply_worker [omapdrm]) from [<c005e8f0>] (process_one_work+0x1b8/0x510)
[ 3155.070922] [<c005e738>] (process_one_work) from [<c005f050>] (worker_thread+0x120/0x394)
[ 3155.092864] [<c005ef30>] (worker_thread) from [<c0065e9c>] (kthread+0xd0/0xec)
[ 3155.111511] [<c0065dcc>] (kthread) from [<c000f648>] (ret_from_fork+0x14/0x2c)
[ 3155.121978] ===========================
[ 3155.121978] 
[ 3155.130920] omapdrm omapdrm.0: rotation '1' ignored for non-tiled fb

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 2379 bytes --]

On 14/04/14 11:43, Tomi Valkeinen wrote:
> On 11/04/14 14:50, Ville Syrjälä wrote:
> 
>>> So the explicit unref done by drm_plane_force_disable() seems a bit out
>>> of place. I can't figure out which drm_framebuffer_reference() would be
>>> the matching one for the unref done by drm_plane_force_disable().
>>>
>>> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
>>> extra in drm_plane_force_disable()?
>>
>> That's the reference that was taken by the drm_mode_setplane() when it
>> succesfully called the .update_plane() hook.
> 
> But drm_mode_setplane() is called via DRM_IOCTL_MODE_SETPLANE, which is
> only used for "proper" planes, not for crtc primary planes, right?
> 
> At least I don't see drm_mode_setplane() in my stack traces, and git
> grep doesn't show it called via any other means than ioctl.
> 
> I am not using any planes from my app, just the crtc and (indirectly)
> its primary plane.

So here's a summary of the fb refs and unrefs. It still seems to me that the
drm_plane_force_disable does an extra unref. Either that, or omapdrm is missing
something that takes the matching reference.

A line like this in the summary below:

2) ref36/3	drm_mode_setcrtc / drm_framebuffer_lookup

Means that "2" is the number I assigned to that ref, and there's a matching
unref with 2) prefix later. ref36/2 means that FB ID 36 was referenced, and ref
count is 3. And the rest of the line shows rough idea of the stack trace where
the ref/unref happens.


# DRM_IOCTL_MODE_ADDFB 2
0) 		kref_init
1) ref36/2	drm_mode_addfb2

# DRM_IOCTL_MODE_SETCRTC
2) ref36/3	drm_mode_setcrtc / drm_framebuffer_lookup
3) ref36/4	drm_mode_setcrtc / drm_mode_set_config_internal
2) unref36/3	drm_mode_setcrtc

# pin new fb
4) ref36/4	apply_worker / omap_plane_pre_apply


# BREAK


# RELEASE
1) unref36/3	drm_release / drm_fb_release / __drm_framebuffer_unregister
3) unref36/2	drm_release / drm_fb_release / drm_framebuffer_remove / drm_mode_set_config_internal
?) unref36/1	drm_release / drm_fb_release / drm_framebuffer_remove / drm_plane_force_disable
0) unref36/0	drm_release / drm_fb_release / drm_framebuffer_remove

# unpin old fb
4) unref36/-1	flip_worker / unpin_worker / drm_framebuffer_unreference


All the other unrefs I can explain, except the drm_plane_force_disable() one.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Rob Clark]

On Tue, Apr 15, 2014 at 5:16 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 14/04/14 11:43, Tomi Valkeinen wrote:
>> On 11/04/14 14:50, Ville Syrjälä wrote:
>>
>>>> So the explicit unref done by drm_plane_force_disable() seems a bit out
>>>> of place. I can't figure out which drm_framebuffer_reference() would be
>>>> the matching one for the unref done by drm_plane_force_disable().
>>>>
>>>> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
>>>> extra in drm_plane_force_disable()?
>>>
>>> That's the reference that was taken by the drm_mode_setplane() when it
>>> succesfully called the .update_plane() hook.
>>
>> But drm_mode_setplane() is called via DRM_IOCTL_MODE_SETPLANE, which is
>> only used for "proper" planes, not for crtc primary planes, right?
>>
>> At least I don't see drm_mode_setplane() in my stack traces, and git
>> grep doesn't show it called via any other means than ioctl.
>>
>> I am not using any planes from my app, just the crtc and (indirectly)
>> its primary plane.
>
> So here's a summary of the fb refs and unrefs. It still seems to me that the
> drm_plane_force_disable does an extra unref. Either that, or omapdrm is missing
> something that takes the matching reference.
>
> A line like this in the summary below:
>
> 2) ref36/3      drm_mode_setcrtc / drm_framebuffer_lookup
>
> Means that "2" is the number I assigned to that ref, and there's a matching
> unref with 2) prefix later. ref36/2 means that FB ID 36 was referenced, and ref
> count is 3. And the rest of the line shows rough idea of the stack trace where
> the ref/unref happens.
>
>
> # DRM_IOCTL_MODE_ADDFB 2
> 0)              kref_init
> 1) ref36/2      drm_mode_addfb2
>
> # DRM_IOCTL_MODE_SETCRTC
> 2) ref36/3      drm_mode_setcrtc / drm_framebuffer_lookup
> 3) ref36/4      drm_mode_setcrtc / drm_mode_set_config_internal
> 2) unref36/3    drm_mode_setcrtc
>
> # pin new fb
> 4) ref36/4      apply_worker / omap_plane_pre_apply
>
>
> # BREAK
>
>
> # RELEASE
> 1) unref36/3    drm_release / drm_fb_release / __drm_framebuffer_unregister
> 3) unref36/2    drm_release / drm_fb_release / drm_framebuffer_remove / drm_mode_set_config_internal
> ?) unref36/1    drm_release / drm_fb_release / drm_framebuffer_remove / drm_plane_force_disable
> 0) unref36/0    drm_release / drm_fb_release / drm_framebuffer_remove
>
> # unpin old fb
> 4) unref36/-1   flip_worker / unpin_worker / drm_framebuffer_unreference
>

Ok, sorry to take so long to comment on the thread, it took me a while
before I had an idea ;-)

so, what triggers this is that previously drm_framebuffer_remove() did
not process private planes.  But now the fb shows up attached to a
plane as well, the crtc's primary plane.

I suspect there is some way in omap_crtc that I must have assumed the
ref the crtc held to the fb was sufficient for the plane to hold the
same ref.  Which is no longer the case.  So somewhere between
omap_crtc and it's primary plane, there now needs to be an extra level
of ref/unref.  So ref should have gone up to 5.

BR,
-R


>
> All the other unrefs I can explain, except the drm_plane_force_disable() one.
>
>  Tomi
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Andrzej Hajda]

On 04/15/2014 12:10 PM, Rob Clark wrote:
> On Tue, Apr 15, 2014 at 5:16 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 14/04/14 11:43, Tomi Valkeinen wrote:
>>> On 11/04/14 14:50, Ville Syrjälä wrote:
>>>
>>>>> So the explicit unref done by drm_plane_force_disable() seems a bit out
>>>>> of place. I can't figure out which drm_framebuffer_reference() would be
>>>>> the matching one for the unref done by drm_plane_force_disable().
>>>>>
>>>>> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
>>>>> extra in drm_plane_force_disable()?
>>>>
>>>> That's the reference that was taken by the drm_mode_setplane() when it
>>>> succesfully called the .update_plane() hook.
>>>
>>> But drm_mode_setplane() is called via DRM_IOCTL_MODE_SETPLANE, which is
>>> only used for "proper" planes, not for crtc primary planes, right?
>>>
>>> At least I don't see drm_mode_setplane() in my stack traces, and git
>>> grep doesn't show it called via any other means than ioctl.
>>>
>>> I am not using any planes from my app, just the crtc and (indirectly)
>>> its primary plane.
>>
>> So here's a summary of the fb refs and unrefs. It still seems to me that the
>> drm_plane_force_disable does an extra unref. Either that, or omapdrm is missing
>> something that takes the matching reference.
>>
>> A line like this in the summary below:
>>
>> 2) ref36/3      drm_mode_setcrtc / drm_framebuffer_lookup
>>
>> Means that "2" is the number I assigned to that ref, and there's a matching
>> unref with 2) prefix later. ref36/2 means that FB ID 36 was referenced, and ref
>> count is 3. And the rest of the line shows rough idea of the stack trace where
>> the ref/unref happens.
>>
>>
>> # DRM_IOCTL_MODE_ADDFB 2
>> 0)              kref_init
>> 1) ref36/2      drm_mode_addfb2
>>
>> # DRM_IOCTL_MODE_SETCRTC
>> 2) ref36/3      drm_mode_setcrtc / drm_framebuffer_lookup
>> 3) ref36/4      drm_mode_setcrtc / drm_mode_set_config_internal
>> 2) unref36/3    drm_mode_setcrtc
>>
>> # pin new fb
>> 4) ref36/4      apply_worker / omap_plane_pre_apply
>>
>>
>> # BREAK
>>
>>
>> # RELEASE
>> 1) unref36/3    drm_release / drm_fb_release / __drm_framebuffer_unregister
>> 3) unref36/2    drm_release / drm_fb_release / drm_framebuffer_remove / drm_mode_set_config_internal
>> ?) unref36/1    drm_release / drm_fb_release / drm_framebuffer_remove / drm_plane_force_disable
>> 0) unref36/0    drm_release / drm_fb_release / drm_framebuffer_remove
>>
>> # unpin old fb
>> 4) unref36/-1   flip_worker / unpin_worker / drm_framebuffer_unreference
>>
> 
> Ok, sorry to take so long to comment on the thread, it took me a while
> before I had an idea ;-)
> 
> so, what triggers this is that previously drm_framebuffer_remove() did
> not process private planes.  But now the fb shows up attached to a
> plane as well, the crtc's primary plane.
> 
> I suspect there is some way in omap_crtc that I must have assumed the
> ref the crtc held to the fb was sufficient for the plane to hold the
> same ref.  Which is no longer the case.  So somewhere between
> omap_crtc and it's primary plane, there now needs to be an extra level
> of ref/unref.  So ref should have gone up to 5.

I have experienced similar problem with exynos_drm. I have found that
in exynos_drm_crtc_mode_set there is line:

	plane->fb = crtc->primary->fb;

without drm_framebuffer_reference.
In result drm_framebuffer_remove dereferences it twice:
- because of crtc->primary->fb == fb,
- because of fb being on dev->mode_config.plane_list

I am not sure how it should be solved properly, but adding
drm_framebuffer_reference in exynos_drm_crtc_mode_set helps.

In omap_plane_mode_set there is also assignment:

	plane->fb = fb

without drm_framebuffer_reference so maybe it can be solved the same way.

Regards
Andrzej

> 
> BR,
> -R
> 
> 
>>
>> All the other unrefs I can explain, except the drm_plane_force_disable() one.
>>
>>  Tomi
>>
>>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1076 bytes --]

On 15/04/14 13:29, Andrzej Hajda wrote:

> I have experienced similar problem with exynos_drm. I have found that
> in exynos_drm_crtc_mode_set there is line:
> 
> 	plane->fb = crtc->primary->fb;
> 
> without drm_framebuffer_reference.
> In result drm_framebuffer_remove dereferences it twice:
> - because of crtc->primary->fb == fb,
> - because of fb being on dev->mode_config.plane_list
> 
> I am not sure how it should be solved properly, but adding
> drm_framebuffer_reference in exynos_drm_crtc_mode_set helps.
> 
> In omap_plane_mode_set there is also assignment:
> 
> 	plane->fb = fb
> 
> without drm_framebuffer_reference so maybe it can be solved the same way.

The omap_plane_mode_set() is called also when using non-primary planes.
For those the refcounting goes right at the moment (I think), so adding
drm_framebuffer_reference() at that func would break it.

I guess I could check if the plane is primary, and add ref only then. Or
add the ref in omap_crtc, before it calls omap_plane_mode_set(). Both
feel a bit hacky...

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1200 bytes --]

On 15/04/14 13:10, Rob Clark wrote:

> so, what triggers this is that previously drm_framebuffer_remove() did
> not process private planes.  But now the fb shows up attached to a
> plane as well, the crtc's primary plane.
> 
> I suspect there is some way in omap_crtc that I must have assumed the
> ref the crtc held to the fb was sufficient for the plane to hold the
> same ref.  Which is no longer the case.  So somewhere between
> omap_crtc and it's primary plane, there now needs to be an extra level
> of ref/unref.  So ref should have gone up to 5.

I still quite lost here... Looking at the non-primary plane's fb ref
counting, some drivers add and remove refs to fb in
plane->plane_update(). But not all.

For omapdrm, update_plane takes a ref, but I'm not quite sure who frees
that ref. Nothing in omap_plane.c seems to do that.

Maybe the ref taken in omapdrm's update_plane is the "same" one that
should be taken for the primary plane also. But I'm not sure where that
should be taken, and if I do take the ref, then I guess it's freed
somewhere else than in omapdrm.

Taking and releasing refs in totally different places is really bad
practice =).

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Rob Clark]

On Tue, Apr 15, 2014 at 6:44 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 15/04/14 13:29, Andrzej Hajda wrote:
>
>> I have experienced similar problem with exynos_drm. I have found that
>> in exynos_drm_crtc_mode_set there is line:
>>
>>       plane->fb = crtc->primary->fb;
>>
>> without drm_framebuffer_reference.
>> In result drm_framebuffer_remove dereferences it twice:
>> - because of crtc->primary->fb == fb,
>> - because of fb being on dev->mode_config.plane_list
>>
>> I am not sure how it should be solved properly, but adding
>> drm_framebuffer_reference in exynos_drm_crtc_mode_set helps.
>>
>> In omap_plane_mode_set there is also assignment:
>>
>>       plane->fb = fb
>>
>> without drm_framebuffer_reference so maybe it can be solved the same way.
>
> The omap_plane_mode_set() is called also when using non-primary planes.
> For those the refcounting goes right at the moment (I think), so adding
> drm_framebuffer_reference() at that func would break it.
>
> I guess I could check if the plane is primary, and add ref only then. Or
> add the ref in omap_crtc, before it calls omap_plane_mode_set(). Both
> feel a bit hacky...

probably split out omap_plane_mode_set_internal(), call that directly
from update_plane() for plane operations.  And then do the refcnt
dance in the new omap_plane_mode_set() which calls _internal()..

BR,
-R

>  Tomi
>
>

Re: Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1921 bytes --]

On 15/04/14 15:24, Rob Clark wrote:

> probably split out omap_plane_mode_set_internal(), call that directly
> from update_plane() for plane operations.  And then do the refcnt
> dance in the new omap_plane_mode_set() which calls _internal()..

We don't actually need that. This did the trick:

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index df1725247cca..3cf31ee59aac 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -225,6 +225,11 @@ int omap_plane_mode_set(struct drm_plane *plane,
                omap_plane->apply_done_cb.arg = arg;
        }

+       if (plane->fb)
+               drm_framebuffer_unreference(plane->fb);
+
+       drm_framebuffer_reference(fb);
+
        plane->fb = fb;
        plane->crtc = crtc;

@@ -241,11 +246,6 @@ static int omap_plane_update(struct drm_plane *plane,
        struct omap_plane *omap_plane = to_omap_plane(plane);
        omap_plane->enabled = true;

-       if (plane->fb)
-               drm_framebuffer_unreference(plane->fb);
-
-       drm_framebuffer_reference(fb);
-
        /* omap_plane_mode_set() takes adjusted src */
        switch (omap_plane->win.rotation & 0xf) {
        case BIT(DRM_ROTATE_90):

With quick tests, works fine so far.

Still I have to say that the ref counting doesn't feel quite right (or
I'm missing something).

As far as I understand, the drm_mode_setplane() gets a ref to the fb,
and stores it in plane->fb. Why do we take a new ref in
omap_plane_update (or with the patch above, in omap_plane_mode_set), and
also store it in plane->fb there? Feels like the same task is done in
two places.

It looks to me like drm_mode_setplane() doesn't really presume that the
update_plane would set plane->fb or plane->crtc, as it does that itself
(and only if update_plane has succeeded).

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Possible fb ref count issue with drm_plane_force_disable()

[Daniel Vetter]

On Tue, Apr 15, 2014 at 12:10 PM, Rob Clark <robdclark@gmail.com> wrote:
> so, what triggers this is that previously drm_framebuffer_remove() did
> not process private planes.  But now the fb shows up attached to a
> plane as well, the crtc's primary plane.

That shouldn're really matter - if we have the fb assigned as the
primary plane then the set_config_internal should clear
crtc->primary->fb. Which means in the next loop (where we go over all
planes) we won't look at it again. Or at least this is how it should
work.

So dropping a ref twice due to that would indeed be a bug, but one in
drm_crtc.c. I have to admit that I don't see it really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: Possible fb ref count issue with drm_plane_force_disable()

[Daniel Vetter]

On Tue, Apr 15, 2014 at 3:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> It looks to me like drm_mode_setplane() doesn't really presume that the
> update_plane would set plane->fb or plane->crtc, as it does that itself
> (and only if update_plane has succeeded).

Yeah that's a bit of historical hilarity. ->set_config should update
crtc->primary->fb, but when calling ->update_plane the drm core will
do this for you. In both cases the plane->fb is the old fb when your
driver hook gets called.

I guess now that we have primary planes we should unify these
semantics a bit since they're fairly pointless.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch