Bug 577120

Summary: possible circular locking dependency in nouveau with 2.6.33 and kms disabled
Product: [Fedora] Fedora Reporter: Arenas Belon, Carlo Marcelo <carenas>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: airlied, ajax, awilliam, bskeggs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-04-12 17:47:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Arenas Belon, Carlo Marcelo 2010-03-26 08:40:36 UTC
Description of problem:


Version-Release number of selected component (if applicable):
0.0.16-2.20100218git2964702

How reproducible:
always

Steps to Reproduce:
1. boot "FC13" kernel without KMS (ro root=/dev/VolGroup00/root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us)
2.
3.
  
Actual results:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.33-1.fc13.i686 #1
-------------------------------------------------------
Xorg/1618 is trying to acquire lock:
 (&mm->mmap_sem){++++++}, at: [<c04c0b9c>] might_fault+0x4c/0x86

but task is already holding lock:
 (&dev->struct_mutex){+.+.+.}, at: [<f7d53b50>] nouveau_gem_ioctl_pushbuf+0x19b/0xa8f [nouveau]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&dev->struct_mutex){+.+.+.}:
       [<c046390b>] __lock_acquire+0xa23/0xb89
       [<c0463b04>] lock_acquire+0x93/0xb1
       [<c07b1b55>] __mutex_lock_common+0x32/0x30a
       [<c07b1eda>] mutex_lock_nested+0x35/0x3d
       [<f7c8a3e7>] drm_mmap+0x2a/0x43 [drm]
       [<f7d54561>] nouveau_ttm_mmap+0x2b/0x3a [nouveau]
       [<c04c7602>] mmap_region+0x246/0x3e3
       [<c04c79e6>] do_mmap_pgoff+0x247/0x297
       [<c04c7afa>] sys_mmap_pgoff+0xc4/0xee
       [<c07b343c>] syscall_call+0x7/0xb

-> #0 (&mm->mmap_sem){++++++}:
       [<c046380d>] __lock_acquire+0x925/0xb89
       [<c0463b04>] lock_acquire+0x93/0xb1
       [<c04c0bb9>] might_fault+0x69/0x86
       [<c05c3846>] copy_to_user+0x34/0x10a
       [<f7d5351d>] validate_list+0x1f8/0x238 [nouveau]
       [<f7d53e90>] nouveau_gem_ioctl_pushbuf+0x4db/0xa8f [nouveau]
       [<f7c8593e>] drm_ioctl+0x26d/0x32b [drm]
       [<c04eaf99>] vfs_ioctl+0x2c/0x96
       [<c04eb54c>] do_vfs_ioctl+0x49b/0x4d9
       [<c04eb5d0>] sys_ioctl+0x46/0x66
       [<c07b343c>] syscall_call+0x7/0xb

other info that might help us debug this:

1 lock held by Xorg/1618:
 #0:  (&dev->struct_mutex){+.+.+.}, at: [<f7d53b50>] nouveau_gem_ioctl_pushbuf+0x19b/0xa8f [nouveau]

stack backtrace:
Pid: 1618, comm: Xorg Not tainted 2.6.33-1.fc13.i686 #1
Call Trace:
 [<c07b08a3>] ? printk+0x14/0x19
 [<c0462bb3>] print_circular_bug+0x91/0x9d
 [<c046380d>] __lock_acquire+0x925/0xb89
 [<c0463b04>] lock_acquire+0x93/0xb1
 [<c04c0b9c>] ? might_fault+0x4c/0x86
 [<c04c0bb9>] might_fault+0x69/0x86
 [<c04c0b9c>] ? might_fault+0x4c/0x86
 [<c05c3846>] copy_to_user+0x34/0x10a
 [<f7d5351d>] validate_list+0x1f8/0x238 [nouveau]
 [<f7d53e90>] nouveau_gem_ioctl_pushbuf+0x4db/0xa8f [nouveau]
 [<f7c8593e>] drm_ioctl+0x26d/0x32b [drm]
 [<f7d539b5>] ? nouveau_gem_ioctl_pushbuf+0x0/0xa8f [nouveau]
 [<c0406481>] ? old_mmap+0x3c/0x53
 [<c058df46>] ? file_has_perm+0x8f/0xa9
 [<c0406481>] ? old_mmap+0x3c/0x53
 [<c04eaf99>] vfs_ioctl+0x2c/0x96
 [<f7c856d1>] ? drm_ioctl+0x0/0x32b [drm]
 [<c04eb54c>] do_vfs_ioctl+0x49b/0x4d9
 [<c0406481>] ? old_mmap+0x3c/0x53
 [<c058e1ea>] ? selinux_file_ioctl+0x43/0x46
 [<c0406481>] ? old_mmap+0x3c/0x53
 [<c04eb5d0>] sys_ioctl+0x46/0x66
 [<c0406481>] ? old_mmap+0x3c/0x53
 [<c07b343c>] syscall_call+0x7/0xb
 [<c0406481>] ? old_mmap+0x3c/0x53
 [<c0406481>] ? old_mmap+0x3c/0x53

Expected results:
no problems initializing video card (VGA compatible controller: nVidia Corporation GeForce 6150SE nForce 430 (rev a2)) by X

Additional info:
booting with plymouth/kms enabled doesn't allow for gdm to start after the boot animation is completed hence why it is disabled, not sure if this problem happens as well when plymouth/kms is enabled, but considering there don't seem to be that many reports about it and I found it every reboot would assume is probably related.

Comment 1 Arenas Belon, Carlo Marcelo 2010-04-01 04:55:23 UTC
also failing if using KMS with 2.6.33.1 (2.6.33.1-19.fc13.i686) that fixed my plymouth problem.

Comment 2 Adam Williamson 2010-04-09 18:09:54 UTC
So you get the same failure with graphical plymouth and KMS, in current F13? What's the actual functional issue here ('possible circular locking dependency' doesn't always cause any real problems...)? Thanks.

Comment 3 Arenas Belon, Carlo Marcelo 2010-04-10 18:56:34 UTC
(In reply to comment #2)
> So you get the same failure with graphical plymouth and KMS, in current F13?

Yes

> What's the actual functional issue here ('possible circular locking dependency'
> doesn't always cause any real problems...)?

I have no functional issue, but my use of the system is limited (don't even have 3D acceleration configured and it fails to work if I do, but unsure is it is related)

Comment 4 Adam Williamson 2010-04-12 17:47:26 UTC
3D failing to work is likely a different issue and not too important anyway (we don't guarantee anything wrt 3D yet).

This looks like a dupe of 572220 to me; please un-dupe if I'm wrong, Ben.



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

*** This bug has been marked as a duplicate of bug 572220 ***