Bug 577120 - possible circular locking dependency in nouveau with 2.6.33 and kms disabled
possible circular locking dependency in nouveau with 2.6.33 and kms disabled
Status: CLOSED DUPLICATE of bug 572220
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-26 04:40 EDT by Arenas Belon, Carlo Marcelo
Modified: 2010-04-12 13:47 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-12 13:47:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Arenas Belon, Carlo Marcelo 2010-03-26 04:40:36 EDT
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 00:55:23 EDT
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 14:09:54 EDT
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 14:56:34 EDT
(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 13:47:26 EDT
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 ***

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