Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756136AbZA1VJ6 (ORCPT ); Wed, 28 Jan 2009 16:09:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751345AbZA1VJs (ORCPT ); Wed, 28 Jan 2009 16:09:48 -0500 Received: from mu-out-0910.google.com ([209.85.134.189]:36744 "EHLO mu-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751569AbZA1VJq (ORCPT ); Wed, 28 Jan 2009 16:09:46 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tT7tNVNJJbvyhjyvnuO8qSXVtICgIzr3Je19EmOIVNmJm8mYpuMpuoCtMLcmyRqXq/ KHq3vmY6d9h1qw7Dc9uX5hj0+1W1CLVJlw8Ghu9U7Sjmgn04UTEzr7p4RWdmFvGyxG41 w5ARUOFjcb/Bvlh8R8UtcoH+Qt2TlNcyIYCU4= MIME-Version: 1.0 Date: Wed, 28 Jan 2009 22:09:44 +0100 Message-ID: Subject: INFO: possible circular locking dependency detected - i915_gem_execbuffer From: Zdenek Kabelac To: Linux Kernel Mailing List Cc: eric@anholt.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6084 Lines: 136 Hi I've got this INFO trace while running glxgears. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.29-rc2 #24 ------------------------------------------------------- glxgears/4212 is trying to acquire lock: (&mm->mmap_sem){----}, at: [] might_fault+0x62/0xc0 but task is already holding lock: (&dev->struct_mutex){--..}, at: [] i915_gem_execbuffer+0xfe/0xde0 [i915] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dev->struct_mutex){--..}: [] __lock_acquire+0x1412/0x1dd0 [] lock_acquire+0x91/0xc0 [] mutex_lock_nested+0xec/0x360 [] drm_vm_open+0x40/0x60 [drm] [] dup_mm+0x291/0x3b0 [] copy_process+0x10c1/0x13f0 [] do_fork+0x90/0x440 [] sys_clone+0x28/0x30 [] stub_clone+0x13/0x20 [] 0xffffffffffffffff -> #1 (&mm->mmap_sem/1){--..}: [] __lock_acquire+0x1412/0x1dd0 [] lock_acquire+0x91/0xc0 [] down_write_nested+0x57/0xa0 [] dup_mm+0xe7/0x3b0 [] copy_process+0x10c1/0x13f0 [] do_fork+0x90/0x440 [] sys_clone+0x28/0x30 [] stub_clone+0x13/0x20 [] 0xffffffffffffffff -> #0 (&mm->mmap_sem){----}: [] __lock_acquire+0x15da/0x1dd0 [] lock_acquire+0x91/0xc0 [] might_fault+0x8f/0xc0 [] i915_emit_box+0x3f/0x300 [i915] [] i915_gem_execbuffer+0xba3/0xde0 [i915] [] drm_ioctl+0x122/0x350 [drm] [] vfs_ioctl+0x85/0xb0 [] do_vfs_ioctl+0x92/0x5b0 [] sys_ioctl+0xa1/0xb0 [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff other info that might help us debug this: 1 lock held by glxgears/4212: #0: (&dev->struct_mutex){--..}, at: [] i915_gem_execbuffer+0xfe/0xde0 [i915] stack backtrace: Pid: 4212, comm: glxgears Not tainted 2.6.29-rc2 #24 Call Trace: [] print_circular_bug_tail+0xe0/0xf0 [] __lock_acquire+0x15da/0x1dd0 [] ? __lock_acquire+0x5ed/0x1dd0 [] ? agp_bind_memory+0xb7/0x100 [] lock_acquire+0x91/0xc0 [] ? might_fault+0x62/0xc0 [] might_fault+0x8f/0xc0 [] ? might_fault+0x62/0xc0 [] ? queue_delayed_work+0x21/0x40 [] i915_emit_box+0x3f/0x300 [i915] [] i915_gem_execbuffer+0xba3/0xde0 [i915] [] ? __mutex_unlock_slowpath+0xf2/0x190 [] drm_ioctl+0x122/0x350 [drm] [] ? cpu_clock+0x50/0x60 [] ? i915_gem_execbuffer+0x0/0xde0 [i915] [] vfs_ioctl+0x85/0xb0 [] do_vfs_ioctl+0x92/0x5b0 [] ? sysret_check+0x27/0x62 [] ? sysret_check+0x27/0x62 [] sys_ioctl+0xa1/0xb0 [] ? trace_hardirqs_off+0xd/0x10 [] system_call_fastpath+0x16/0x1b BTW - now I'm getting finally again number I used to see 1.5 year ago on the same hardware - which is 1100FPS - though I had to turn on performance governor or change threshold for ondemand governor - I'm not sure why the standard threshold doesn't handle this well (i.e. it give only 700FPS) Also it's interesting that lock_stat give this huge contention entry fro gem driver - maybe it could be handled better ? lock_stat version 0.3 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- class name con-bounces contentions waittime-min waittime-max waittime-total acq-bounces acquisitions holdtime-min holdtime-max holdtime-total ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- &dev->struct_mutex: 113 4256313 27.38 24269683.29 13424452821900 30701 10006488 1.07 53443.29 48405221.21 ------------------ &dev->struct_mutex 78 [] i915_gem_retire_work_handler+0x3f/0x90 [i915] &dev->struct_mutex 34 [] i915_gem_set_domain_ioctl+0x9f/0x110 [i915] &dev->struct_mutex 17 [] i915_gem_busy_ioctl+0x37/0xd0 [i915] &dev->struct_mutex 19 [] i915_gem_sw_finish_ioctl+0x66/0xd0 [i915] ------------------ &dev->struct_mutex 10 [] i915_gem_busy_ioctl+0x37/0xd0 [i915] &dev->struct_mutex 63 [] i915_gem_retire_work_handler+0x3f/0x90 [i915] &dev->struct_mutex 13 [] i915_gem_throttle_ioctl+0x31/0x70 [i915] &dev->struct_mutex 5 [] i915_gem_sw_finish_ioctl+0x66/0xd0 [i915] Zdenek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/