Fedora Account System
Red Hat Associate
Red Hat Customer
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.
also failing if using KMS with 2.6.33.1 (2.6.33.1-19.fc13.i686) that fixed my plymouth problem.
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.
(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)
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 ***