Bug 13030
Summary: | i915: possible circular locking dependency detected in i915_gem_execbuffer | ||
---|---|---|---|
Product: | Drivers | Reporter: | Sami Liedes (sami.liedes) |
Component: | Video(DRI - Intel) | Assignee: | drivers_video-dri-intel (drivers_video-dri-intel) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | eric, gordon.jin, sergio |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.29.1 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | Dmesg output, except the very first seconds that I didn't capture |
Description
Sami Liedes
2009-04-06 23:18:20 UTC
same here , on boot Running glxgears I saw in dmesg [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.29.1-42.rc1.sb3.fc10.i686.PAE #1 ------------------------------------------------------- X/2749 is trying to acquire lock: (&mm->mmap_sem){----}, at: [<c049c6f2>] 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){--..}: [<c045a398>] __lock_acquire+0x9a8/0xb1b [<c045a566>] lock_acquire+0x5b/0x81 [<c073a7c0>] __mutex_lock_common+0xda/0x32e [<c073aabb>] mutex_lock_nested+0x33/0x3b [<f81bc7b0>] drm_gem_mmap+0x34/0xf8 [drm] [<c04a395f>] mmap_region+0x255/0x3f9 [<c04a3d4a>] do_mmap_pgoff+0x247/0x297 [<c040c739>] sys_mmap2+0x5f/0x80 [<c040966b>] sysenter_do_call+0x12/0x3f [<ffffffff>] 0xffffffff -> #0 (&mm->mmap_sem){----}: [<c045a26d>] __lock_acquire+0x87d/0xb1b [<c045a566>] lock_acquire+0x5b/0x81 [<c049c70f>] might_fault+0x65/0x85 [<c057dbcc>] copy_from_user+0x2f/0x117 [<f8353d55>] i915_gem_execbuffer+0x2c3/0xad7 [i915] [<f81bb8c2>] drm_ioctl+0x1c4/0x241 [drm] [<c04c19d7>] vfs_ioctl+0x55/0x6e [<c04c1f28>] do_vfs_ioctl+0x46f/0x4a8 [<c04c1fa6>] 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/2749: #0: (&dev->struct_mutex){--..}, at: [<f8353b97>] i915_gem_execbuffer+0x105/0xad7 [i915] stack backtrace: Pid: 2749, comm: X Not tainted 2.6.29.1-42.rc1.sb3.fc10.i686.PAE #1 Call Trace: [<c0739533>] ? printk+0x14/0x19 [<c04597d9>] print_circular_bug_tail+0x5d/0x68 [<c045a26d>] __lock_acquire+0x87d/0xb1b [<c045a566>] lock_acquire+0x5b/0x81 [<c049c6f2>] ? might_fault+0x48/0x85 [<c049c70f>] might_fault+0x65/0x85 [<c049c6f2>] ? might_fault+0x48/0x85 [<c057dbcc>] copy_from_user+0x2f/0x117 [<f8353d55>] i915_gem_execbuffer+0x2c3/0xad7 [i915] [<c04b0e39>] ? __slab_alloc+0x3d0/0x445 [<c049c72d>] ? might_fault+0x83/0x85 [<c057dbcc>] ? copy_from_user+0x2f/0x117 [<f81bb8c2>] drm_ioctl+0x1c4/0x241 [drm] [<f8353a92>] ? i915_gem_execbuffer+0x0/0xad7 [i915] [<c04c19d7>] vfs_ioctl+0x55/0x6e [<c04c1f28>] do_vfs_ioctl+0x46f/0x4a8 [<c0580d08>] ? _raw_spin_unlock+0x74/0x78 [<c04b6ca2>] ? fsnotify_modify+0x54/0x5f [<c04b6e93>] ? do_sync_write+0x0/0xee [<c04b77af>] ? vfs_write+0xa9/0xe4 [<c04c1fa6>] sys_ioctl+0x45/0x5f [<c040966b>] sysenter_do_call+0x12/0x3f Created attachment 20861 [details]
Dmesg output, except the very first seconds that I didn't capture
Here's my dmesg. The first seconds are missing, I guess, because of the vast amount of kobject: debug messages before the disk logging started.
This has been fixed in master, but hasn't been sent to stable due to known regressions that will be fixed soon. (In reply to comment #3) > This has been fixed in master, but hasn't been sent to stable due to known > regressions that will be fixed soon. the master of what ? (drm-next, libdrm, mesa , drv-intel or xserver) A lock order fix could only occur in the kernel, and master refers to linus. This should have been fixed in 2.6.30 according to Eric's comment. |