<div dir="ltr"><div><div>Hi Rob,<br><br></div>Thanks for your comment.<br>Looking at the working  omapdrm code in 3.4.25, added the spin_unlock at the start of the function sync_op_update() and again locking at the end of the function fixes this error.<br>
</div>Does this looks correct fix?<br><div><br>-------------------------------------------------------------------------<br>static void sync_op_update(void)<br>{<br>    struct omap_gem_sync_waiter *waiter, *n;<br>    + spin_unlock(&sync_lock); //vikas<br>
    list_for_each_entry_safe(waiter, n, &waiters, list) {<br>        if (!is_waiting(waiter)) {<br>            list_del(&waiter->list);<br>            SYNC("notify: %p", waiter);<br>            waiter->notify(waiter->arg);<br>
            kfree(waiter);<br>        }<br>    }<br>   + spin_lock(&sync_lock);<br>}<br><div><div><div><div class="gmail_extra">-------------------------------------------------------------------------<br><br></div><div class="gmail_extra">
Thanks & Regards,<br></div><div class="gmail_extra">Vikas<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 2, 2014 at 8:01 PM, Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On Wed, Apr 2, 2014 at 8:23 AM, Vikas Patil <<a href="mailto:vikasmpatil@gmail.com">vikasmpatil@gmail.com</a>> wrote:<br>

> Hi,<br>
> I am seeing following kernel backtrace on J6 with linux 3.8.13 when trying<br>
> to start IVI LM service. Before starting this I started the X11 and run some<br>
> GLES2/X11 based tests successfully.<br>
><br>
> The same binaries and my graphics driver are working fine on OMAP5 and linux<br>
> 3.4.25. Is this some known BUG in omapdrm driver? If not a bug then how<br>
> should I go for debugging it?<br>
><br>
> From the trace what I understood is, this is case of nested spinlock and I<br>
> might be seeing this error due to this as in the trace omap_gem_op_update()<br>
> and omap_gem_set_sync_object(), both functions are trying to acquire<br>
> spin_lock(&sync_lock).<br>
><br>
<br>
</div>ok, to be fair this is more about pvr and some downstream patches to<br>
omapdrm to make it work with pvr, than the upstream omapdrm.<br>
<br>
tbh, I don't completely remember how this used to work.. it doesn't<br>
seem like the sort of thing that could be easily missed.  You might<br>
want to compare to older omapdrm+pvr, I might have moved some of the<br>
locking around?<br>
<br>
Probably the best/safest thing would be to move the waiter->notify()<br>
callback off to omapdrm's workqueue, so it isn't called with spinlocks<br>
held.<br>
<br>
BR,<br>
-R<br>
<br>
><br>
> [  719.005340] BUG: spinlock lockup suspected on CPU#0, kworker/u:2/787<br>
<div class=""><div class="h5">> [  719.011749]  lock: sync_lock+0x0/0x20, .magic: dead4ead, .owner:<br>
> kworker/u:2/787, .owner_cpu: 0<br>
> [  719.020507] [<c001bbc0>] (unwind_backtrace+0x0/0x138) from [<c02896d0>]<br>
> (do_raw_spin_lock+0x100/0x17c)<br>
> [  719.029876] [<c02896d0>] (do_raw_spin_lock+0x100/0x17c) from [<c03157ec>]<br>
> (omap_gem_set_sync_object+0x14/0xf4)<br>
> [  719.039978] [<c03157ec>] (omap_gem_set_sync_object+0x14/0xf4) from<br>
> [<bf0091f4>] (FreeMemCallBackCommon+0xf4/0x24c [omapdrm_pvr])<br>
> [  719.051635] [<bf0091f4>] (FreeMemCallBackCommon+0xf4/0x24c [omapdrm_pvr])<br>
> from [<bf0093d0>] (UnwrapExtMemoryCallBack+0x28/0x68 [omapdrm_pvr])<br>
> [  719.064544] [<bf0093d0>] (UnwrapExtMemoryCallBack+0x28/0x68<br>
> [omapdrm_pvr]) from [<bf013d3c>] (FreeResourceByPtr.part.0+0xac/0xcc<br>
> [omapdrm_pvr])<br>
> [  719.077575] [<bf013d3c>] (FreeResourceByPtr.part.0+0xac/0xcc<br>
> [omapdrm_pvr]) from [<bf0144d0>] (ResManFreeResByPtr+0x44/0x6c<br>
> [omapdrm_pvr])<br>
> [  719.090118] [<bf0144d0>] (ResManFreeResByPtr+0x44/0x6c [omapdrm_pvr])<br>
> from [<bf008980>] (async_unmap+0x28/0x44 [omapdrm_pvr])<br>
> [  719.101531] [<bf008980>] (async_unmap+0x28/0x44 [omapdrm_pvr]) from<br>
> [<c0315528>] (sync_op_update+0x88/0xa8)<br>
> [  719.111328] [<c0315528>] (sync_op_update+0x88/0xa8) from [<c03157c8>]<br>
> (omap_gem_op_update+0x14/0x24)<br>
> [  719.120544] [<c03157c8>] (omap_gem_op_update+0x14/0x24) from [<bf010578>]<br>
> (PVRSRVMISR+0xc/0x60 [omapdrm_pvr])<br>
> [  719.130523] [<bf010578>] (PVRSRVMISR+0xc/0x60 [omapdrm_pvr]) from<br>
> [<c005a810>] (process_one_work+0x1c8/0x5c0)<br>
> [  719.140502] [<c005a810>] (process_one_work+0x1c8/0x5c0) from [<c005af58>]<br>
> (worker_thread+0x168/0x444)<br>
> [  719.149810] [<c005af58>] (worker_thread+0x168/0x444) from [<c005fa40>]<br>
> (kthread+0xa4/0xb0)<br>
> [  719.158142] [<c005fa40>] (kthread+0xa4/0xb0) from [<c00140d0>]<br>
> (ret_from_fork+0x14/0x24)<br>
><br>
> Thanking you for your time.<br>
><br>
> Thanks & Regards,<br>
> Vikas<br>
</div></div></blockquote></div><br></div></div></div></div></div></div>