spinlock lockup suspected on CPU error on omapdrm

[Vikas Patil]

Hi Rob,

Thanks for your comment.
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.
Does this looks correct fix?

-------------------------------------------------------------------------
static void sync_op_update(void)
{
    struct omap_gem_sync_waiter *waiter, *n;
    + spin_unlock(&sync_lock); //vikas
    list_for_each_entry_safe(waiter, n, &waiters, list) {
        if (!is_waiting(waiter)) {
            list_del(&waiter->list);
            SYNC("notify: %p", waiter);
            waiter->notify(waiter->arg);
            kfree(waiter);
        }
    }
   + spin_lock(&sync_lock);
}
-------------------------------------------------------------------------

Thanks & Regards,
Vikas

On Wed, Apr 2, 2014 at 8:01 PM, Rob Clark <robdclark at gmail.com> wrote:

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