Bug 572220 - INFO: possible circular locking dependency detected - nouveau_gem_ioctl_pushbuf
Summary: INFO: possible circular locking dependency detected - nouveau_gem_ioctl_pushbuf
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 577120 579668 589011 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-10 15:23 UTC by Stefan Ring
Modified: 2011-07-07 15:49 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-05 22:12:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
log excerpt (4.76 KB, application/octet-stream)
2010-03-10 15:23 UTC, Stefan Ring
no flags Details

Description Stefan Ring 2010-03-10 15:23:53 UTC
Created attachment 399110 [details]
log excerpt

Version-Release number of selected component (if applicable):
2.6.33-1.fc13.x86_64 #1


How reproducible:
I don't know; I've been running a GNOME-session all day without doing anything fancy.

Actual results:

see attached file


Additional info:

Hardware is a Compaq dc7900 with nVidia Corporation Quadro NVS 290 (rev a1)

Comment 1 Stefan Ring 2010-03-12 08:20:19 UTC
Comment on attachment 399110 [details]
log excerpt

Let's put it here, so google can find it:

Mar 10 12:11:55 localhost kernel: =======================================================
Mar 10 12:11:55 localhost kernel: [ INFO: possible circular locking dependency detected ]
Mar 10 12:11:55 localhost kernel: 2.6.33-1.fc13.x86_64 #1
Mar 10 12:11:55 localhost kernel: -------------------------------------------------------
Mar 10 12:11:55 localhost kernel: Xorg/1601 is trying to acquire lock:
Mar 10 12:11:55 localhost kernel: (&mm->mmap_sem){++++++}, at: [<ffffffff810f1a00>] might_fault+0x5c/0xac
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel: but task is already holding lock:
Mar 10 12:11:55 localhost kernel: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa007efb9>] nouveau_gem_ioctl_pushbuf+0x1e8/0x
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel: which lock already depends on the new lock.
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel: the existing dependency chain (in reverse order) is:
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel: -> #1 (&dev->struct_mutex){+.+.+.}:
Mar 10 12:11:55 localhost kernel:       [<ffffffff8107e817>] __lock_acquire+0xb7d/0xd2c
Mar 10 12:11:55 localhost kernel:       [<ffffffff8107eaa2>] lock_acquire+0xdc/0x102
Mar 10 12:11:55 localhost kernel:       [<ffffffff81477025>] __mutex_lock_common+0x4b/0x392
Mar 10 12:11:55 localhost kernel:       [<ffffffff81477430>] mutex_lock_nested+0x3e/0x43
Mar 10 12:11:55 localhost kernel:       [<ffffffffa001ede9>] drm_mmap+0x38/0x5f [drm]
Mar 10 12:11:55 localhost kernel:       [<ffffffffa007fc3a>] nouveau_ttm_mmap+0x34/0x46 [nouveau]
Mar 10 12:11:55 localhost kernel:       [<ffffffff810fa0a5>] mmap_region+0x2ac/0x4cb
Mar 10 12:11:55 localhost kernel:       [<ffffffff810fa55c>] do_mmap_pgoff+0x298/0x2fb
Mar 10 12:11:55 localhost kernel:       [<ffffffff810fa6b5>] sys_mmap_pgoff+0xf6/0x12e
Mar 10 12:11:55 localhost kernel:       [<ffffffff8100dd89>] sys_mmap+0x22/0x24
Mar 10 12:11:55 localhost kernel:       [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel: -> #0 (&mm->mmap_sem){++++++}:
Mar 10 12:11:55 localhost kernel:       [<ffffffff8107e6c1>] __lock_acquire+0xa27/0xd2c
Mar 10 12:11:55 localhost kernel:       [<ffffffff8107eaa2>] lock_acquire+0xdc/0x102
Mar 10 12:11:55 localhost kernel:       [<ffffffff810f1a2d>] might_fault+0x89/0xac
Mar 10 12:11:55 localhost kernel:       [<ffffffffa007e849>] validate_list+0x22b/0x288 [nouveau]
Mar 10 12:11:55 localhost kernel:       [<ffffffffa007fa7a>] nouveau_gem_ioctl_pushbuf+0xca9/0xcdf [nouveau]
Mar 10 12:11:55 localhost kernel:       [<ffffffffa0019418>] drm_ioctl+0x28f/0x373 [drm]
Mar 10 12:11:55 localhost kernel:       [<ffffffff8112bcfc>] vfs_ioctl+0x32/0xa6
Mar 10 12:11:55 localhost kernel:       [<ffffffff8112c27c>] do_vfs_ioctl+0x490/0x4d6
Mar 10 12:11:55 localhost kernel:       [<ffffffff8112c318>] sys_ioctl+0x56/0x79
Mar 10 12:11:55 localhost kernel:       [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel: other info that might help us debug this:
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel: 1 lock held by Xorg/1601:
Mar 10 12:11:55 localhost kernel: #0:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa007efb9>] nouveau_gem_ioctl_pushbuf+0x1
Mar 10 12:11:55 localhost kernel:
Mar 10 12:11:55 localhost kernel: stack backtrace:
Mar 10 12:11:55 localhost kernel: Pid: 1601, comm: Xorg Not tainted 2.6.33-1.fc13.x86_64 #1
Mar 10 12:11:55 localhost kernel: Call Trace:
Mar 10 12:11:55 localhost kernel: [<ffffffff8107d871>] print_circular_bug+0xaf/0xbd
Mar 10 12:11:55 localhost kernel: [<ffffffff8107e6c1>] __lock_acquire+0xa27/0xd2c
Mar 10 12:11:55 localhost kernel: [<ffffffff8107eaa2>] lock_acquire+0xdc/0x102
Mar 10 12:11:55 localhost kernel: [<ffffffff810f1a00>] ? might_fault+0x5c/0xac
Mar 10 12:11:55 localhost kernel: [<ffffffff810f1a2d>] might_fault+0x89/0xac
Mar 10 12:11:55 localhost kernel: [<ffffffff810f1a00>] ? might_fault+0x5c/0xac
Mar 10 12:11:55 localhost kernel: [<ffffffffa0061fc5>] ? ttm_bo_validate+0xae/0xf7 [ttm]
Mar 10 12:11:55 localhost kernel: [<ffffffffa007e849>] validate_list+0x22b/0x288 [nouveau]
Mar 10 12:11:55 localhost kernel: [<ffffffffa007fa7a>] nouveau_gem_ioctl_pushbuf+0xca9/0xcdf [nouveau]
Mar 10 12:11:55 localhost kernel: [<ffffffffa0019418>] drm_ioctl+0x28f/0x373 [drm]
Mar 10 12:11:55 localhost kernel: [<ffffffffa007edd1>] ? nouveau_gem_ioctl_pushbuf+0x0/0xcdf [nouveau]
Mar 10 12:11:55 localhost kernel: [<ffffffff8112bcfc>] vfs_ioctl+0x32/0xa6
Mar 10 12:11:55 localhost kernel: [<ffffffff8112c27c>] do_vfs_ioctl+0x490/0x4d6
Mar 10 12:11:55 localhost kernel: [<ffffffff8112c318>] sys_ioctl+0x56/0x79
Mar 10 12:11:55 localhost kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b

Comment 2 Adam Williamson 2010-04-12 17:47:18 UTC
*** Bug 579668 has been marked as a duplicate of this bug. ***

Comment 3 Adam Williamson 2010-04-12 17:47:26 UTC
*** Bug 577120 has been marked as a duplicate of this bug. ***

Comment 4 Adam Williamson 2010-04-12 17:48:16 UTC
Setting this low severity as it doesn't seem to have any visible negative effects.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 5 Ben Skeggs 2010-06-02 02:20:07 UTC
*** Bug 589011 has been marked as a duplicate of this bug. ***

Comment 6 Bug Zapper 2011-06-02 16:14:49 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Stefan Ring 2011-06-03 07:06:30 UTC
Haven't seen this in a very long time; definitely never on F14.

Comment 8 Ben Skeggs 2011-06-05 22:12:10 UTC
Thanks for the update!

Comment 9 Stefan Ring 2011-06-29 20:13:24 UTC
(In reply to comment #7)
> Haven't seen this in a very long time; definitely never on F14.

Although, upon second thought, that doesn't mean anything, as these kernels don't have lock debugging enabled. I'll try to run an enabled kernel for the next few days and see if anything turns up.

Comment 10 Stefan Ring 2011-07-07 15:49:14 UTC
No, not happening anymore.


Note You need to log in before you can comment on or make changes to this bug.