http://bugzilla.kernel.org/show_bug.cgi?id=12419
Sérgio M Basto <ser...@sergiomb.no-ip.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ser...@sergiomb.no-ip.org
--- Comment #16 from Sérgio M Basto <ser...@sergiomb.no-ip.org> 2009-03-31
02:10:22 ---
(In reply to comment #13)
> Thanks for the report. I think this was the bug:
>
> - ret = i915_dispatch_cmdbuffer(dev, cmdbuf, cliprects, data);
> + ret = i915_dispatch_cmdbuffer(dev, cmdbuf, cliprects, batch_data);
>
> but I still haven't actually tested that path yet (been trying to get the GEM
> paths solid). New for-review pushed.
I don't find the code which have "ret = i915_dispatch_cmdbuffer(dev, cmdbuf,
cliprects," for check it out, this is for libdrm, for kernel or for drive ?
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-16.fc10.i686.PAE #1
-------------------------------------------------------
X/2732 is trying to acquire lock:
(&mm->mmap_sem){----}, at: [<c049c5ea>] might_fault+0x48/0x85
but task is already holding lock:
(&dev->struct_mutex){--..}, at: [<f8353b97>] i915_gem_execbuffer+0x105/0xad7
[i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&dev->struct_mutex){--..}:
[<c045a290>] __lock_acquire+0x9a8/0xb1b
[<c045a45e>] lock_acquire+0x5b/0x81
[<c070ff00>] __mutex_lock_common+0xda/0x32e
[<c07101fb>] mutex_lock_nested+0x33/0x3b
[<f81bc7b0>] drm_gem_mmap+0x34/0xf8 [drm]
[<c04a384f>] mmap_region+0x255/0x3f9
[<c04a3c3a>] do_mmap_pgoff+0x247/0x297
[<c040c739>] sys_mmap2+0x5f/0x80
[<c040966b>] sysenter_do_call+0x12/0x3f
[<ffffffff>] 0xffffffff
-> #0 (&mm->mmap_sem){----}:
[<c045a165>] __lock_acquire+0x87d/0xb1b
[<c045a45e>] lock_acquire+0x5b/0x81
[<c049c607>] might_fault+0x65/0x85
[<c055330c>] copy_from_user+0x2f/0x117
[<f8353d55>] i915_gem_execbuffer+0x2c3/0xad7 [i915]
[<f81bb8c2>] drm_ioctl+0x1c4/0x241 [drm]
[<c04c18c7>] vfs_ioctl+0x55/0x6e
[<c04c1e18>] do_vfs_ioctl+0x46f/0x4a8
[<c04c1e96>] sys_ioctl+0x45/0x5f
[<c040966b>] sysenter_do_call+0x12/0x3f
[<ffffffff>] 0xffffffff
other info that might help us debug this:
1 lock held by X/2732:
#0: (&dev->struct_mutex){--..}, at: [<f8353b97>]
i915_gem_execbuffer+0x105/0xad7 [i915]
stack backtrace:
Pid: 2732, comm: X Not tainted 2.6.29-16.fc10.i686.PAE #1
Call Trace:
[<c070ec6f>] ? printk+0x14/0x1d
[<c04596d1>] print_circular_bug_tail+0x5d/0x68
[<c045a165>] __lock_acquire+0x87d/0xb1b
[<c045a45e>] lock_acquire+0x5b/0x81
[<c049c5ea>] ? might_fault+0x48/0x85
[<c049c607>] might_fault+0x65/0x85
[<c049c5ea>] ? might_fault+0x48/0x85
[<c055330c>] copy_from_user+0x2f/0x117
[<f8353d55>] i915_gem_execbuffer+0x2c3/0xad7 [i915]
[<c04b0d29>] ? __slab_alloc+0x3d0/0x445
[<c049c625>] ? might_fault+0x83/0x85
[<c055330c>] ? copy_from_user+0x2f/0x117
[<f81bb8c2>] drm_ioctl+0x1c4/0x241 [drm]
[<f8353a92>] ? i915_gem_execbuffer+0x0/0xad7 [i915]
[<c04c18c7>] vfs_ioctl+0x55/0x6e
[<c04c1e18>] do_vfs_ioctl+0x46f/0x4a8
[<c0556448>] ? _raw_spin_unlock+0x74/0x78
[<c04b6b92>] ? fsnotify_modify+0x54/0x5f
[<c04b6d83>] ? do_sync_write+0x0/0xee
[<c04b769f>] ? vfs_write+0xa9/0xe4
[<c04c1e96>] sys_ioctl+0x45/0x5f
[<c040966b>] sysenter_do_call+0x12/0x3f
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
