Dave Airlie wrote:
> =============================================
>
> [ INFO: possible recursive locking detected ]
>
> 2.6.24-0.123.rc6.fc9 #1
>
> ---------------------------------------------
>
> glxgears/2563 is trying to acquire lock:
>
> (&bo->mutex){--..}, at: [<f8b42838>] drm_bo_mem_space+0x27a/0x356 [drm]
>
>
>
> but task is already holding lock:
>
> (&bo->mutex){--..}, at: [<f8b42dff>] drm_bo_do_validate+0x26/0x9c [drm]
>
>
>
> other info that might help us debug this:
>
> 3 locks held by glxgears/2563:
>
> ]
> #0: (&dev_priv->cmdbuf_mutex){--..}, at: [<f8dfcaa2>]
> i915_execbuffer+0x104/0
> #1: (&bo->mutex){--..}, at: [<f8b42dff>] drm_bo_do_validate+0x26/0x9c
> [drm] ]
> #2: (&dev->bm.evict_mutex){--..}, at: [<f8b42986>]
> drm_bo_move_buffer+0x72/0x
> stack backtrace:
> Pid: 10655, comm: glxgears Not tainted 2.6.24-0.123.rc6.fc9 #1
> [<c040649a>] show_trace_log_lvl+0x1a/0x2f
> [<c0406d55>] show_trace+0x12/0x14
> [<c0407075>] dump_stack+0x6c/0x72
> [<c044cee3>] __lock_acquire+0x815/0xb5f
> [<c044d625>] lock_acquire+0x7b/0x9e
> [<c063cd1b>] mutex_lock_nested+0xec/0x282
> [<f9016838>] drm_bo_mem_space+0x27a/0x356 [drm]
> [<f90169bc>] drm_bo_move_buffer+0xa8/0x17b [drm]
> [<f9016c27>] drm_buffer_object_validate+0x198/0x34a [drm]
> [<f9016e50>] drm_bo_do_validate+0x77/0x9c [drm]
> [<f9016f0f>] drm_bo_handle_validate+0x9a/0xc2 [drm]
> [<f8b4c898>] i915_validate_buffer_list+0x24f/0x36d [i915]
> [<f8b4db18>] i915_execbuffer+0x17a/0x356 [i915]
> [<f900c457>] drm_unlocked_ioctl+0x1d3/0x257 [drm]
> [<f900c4ea>] drm_ioctl+0xf/0x11 [drm]
> [<c049ce94>] do_ioctl+0x50/0x67
> [<c049d0f4>] vfs_ioctl+0x249/0x25c
> [<c049d149>] sys_ioctl+0x42/0x5d
> [<c0405252>] syscall_call+0x7/0xb
>
>
> it looks like we can get into drm_bo_mem_force_space, while holding a
> bo->mutex, then it might be possible to iterate the lru and find the
> current bo and lock it again.. now something else might stop this but the
> lockdep may need to be thought about it..
>
> Dave.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
Dave,
We've seen this on occasions before but never been able to track it
down, so if you
have a reliable way to reproduce it would be super.
When drm_bo_mem_space() is called for a buffer, that buffer should no
longer be on the lru lists,
but it is obvious from the error message it's trying to evict itself.
/Thomas
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
