Found this in dmesg output: [ 1429.194978] ====================================================== [ 1429.194979] [ INFO: possible circular locking dependency detected ] [ 1429.194980] 4.10.0-0.rc2.git2.1.fc26.x86_64 #1 Tainted: G E [ 1429.194981] ------------------------------------------------------- [ 1429.194982] Xorg/4621 is trying to acquire lock: [ 1429.194982] (&dev->struct_mutex){+.+.+.}, at: [<ffffffffc0194eca>] drm_gem_object_unreference_unlocked+0xa/0xe0 [drm] [ 1429.194991] but task is already holding lock: [ 1429.194992] (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc05223d9>] validate_init.isra.8+0x219/0x7f0 [nouveau] [ 1429.195014] which lock already depends on the new lock. [ 1429.195015] the existing dependency chain (in reverse order) is: [ 1429.195016] -> #1 (reservation_ww_class_mutex){+.+.+.}: [ 1429.195018] [ 1429.195020] [<ffffffff95118906>] lock_acquire+0xf6/0x1f0 [ 1429.195021] [ 1429.195023] [<ffffffff95954b89>] mutex_lock_nested+0x89/0x6e0 [ 1429.195023] [ 1429.195037] [<ffffffffc0334ae6>] i915_gem_do_execbuffer.isra.37+0x1936/0x1da0 [i915] [ 1429.195038] [ 1429.195048] [<ffffffffc033538f>] i915_gem_execbuffer2+0xcf/0x260 [i915] [ 1429.195048] [ 1429.195054] [<ffffffffc01962aa>] drm_ioctl+0x37a/0x4e0 [drm] [ 1429.195054] [ 1429.195056] [<ffffffff952d6723>] do_vfs_ioctl+0xa3/0x740 [ 1429.195057] [ 1429.195058] [<ffffffff952d6e39>] SyS_ioctl+0x79/0x90 [ 1429.195059] [ 1429.195061] [<ffffffff95959fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2 [ 1429.195061] -> #0 (&dev->struct_mutex){+.+.+.}: [ 1429.195063] [ 1429.195064] [<ffffffff95118315>] __lock_acquire+0x10e5/0x1270 [ 1429.195065] [ 1429.195066] [<ffffffff95118906>] lock_acquire+0xf6/0x1f0 [ 1429.195067] [ 1429.195071] [<ffffffffc0194f05>] drm_gem_object_unreference_unlocked+0x45/0xe0 [drm] [ 1429.195072] [ 1429.195089] [<ffffffffc0522156>] validate_fini_no_ticket+0xb6/0x120 [nouveau] [ 1429.195090] [ 1429.195105] [<ffffffffc05234e2>] nouveau_gem_ioctl_pushbuf+0x312/0x10c0 [nouveau] [ 1429.195106] [ 1429.195110] [<ffffffffc01962aa>] drm_ioctl+0x37a/0x4e0 [drm] [ 1429.195111] [ 1429.195126] [<ffffffffc0519be4>] nouveau_drm_ioctl+0x74/0xc0 [nouveau] [ 1429.195127] [ 1429.195128] [<ffffffff952d6723>] do_vfs_ioctl+0xa3/0x740 [ 1429.195129] [ 1429.195130] [<ffffffff952d6e39>] SyS_ioctl+0x79/0x90 [ 1429.195130] [ 1429.195132] [<ffffffff95959fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2 [ 1429.195133] other info that might help us debug this: [ 1429.195134] Possible unsafe locking scenario: [ 1429.195135] CPU0 CPU1 [ 1429.195135] ---- ---- [ 1429.195136] lock(reservation_ww_class_mutex); [ 1429.195137] lock(&dev->struct_mutex); [ 1429.195138] lock(reservation_ww_class_mutex); [ 1429.195139] lock(&dev->struct_mutex); [ 1429.195141] *** DEADLOCK *** [ 1429.195143] 3 locks held by Xorg/4621: [ 1429.195143] #0: (&cli->mutex){+.+.+.}, at: [<ffffffffc0538c60>] nouveau_abi16_get+0x30/0x70 [nouveau] [ 1429.195160] #1: (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffffc05235d5>] nouveau_gem_ioctl_pushbuf+0x405/0x10c0 [nouveau] [ 1429.195175] #2: (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc05223d9>] validate_init.isra.8+0x219/0x7f0 [nouveau] [ 1429.195190] stack backtrace: [ 1429.195192] CPU: 2 PID: 4621 Comm: Xorg Tainted: G E 4.10.0-0.rc2.git2.1.fc26.x86_64 #1 [ 1429.195193] Hardware name: LENOVO 20FXS0BB14/20FXS0BB14, BIOS R07ET63W (2.03 ) 03/15/2016 [ 1429.195193] Call Trace: [ 1429.195195] dump_stack+0x86/0xc3 [ 1429.195197] print_circular_bug+0x1be/0x210 [ 1429.195199] __lock_acquire+0x10e5/0x1270 [ 1429.195200] lock_acquire+0xf6/0x1f0 [ 1429.195205] ? drm_gem_object_unreference_unlocked+0xa/0xe0 [drm] [ 1429.195210] drm_gem_object_unreference_unlocked+0x45/0xe0 [drm] [ 1429.195214] ? drm_gem_object_unreference_unlocked+0xa/0xe0 [drm] [ 1429.195228] validate_fini_no_ticket+0xb6/0x120 [nouveau] [ 1429.195242] nouveau_gem_ioctl_pushbuf+0x312/0x10c0 [nouveau] [ 1429.195247] drm_ioctl+0x37a/0x4e0 [drm] [ 1429.195249] ? sched_clock_cpu+0xa7/0xc0 [ 1429.195262] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau] [ 1429.195264] ? trace_hardirqs_on+0xd/0x10 [ 1429.195278] nouveau_drm_ioctl+0x74/0xc0 [nouveau] [ 1429.195280] do_vfs_ioctl+0xa3/0x740 [ 1429.195281] ? up_read+0x1f/0x40 [ 1429.195282] SyS_ioctl+0x79/0x90 [ 1429.195284] entry_SYSCALL_64_fastpath+0x1f/0xc2 [ 1429.195285] RIP: 0033:0x7fd63f1a7757 [ 1429.195286] RSP: 002b:00007ffe53bbe7e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1429.195287] RAX: ffffffffffffffda RBX: 00000000027e3c10 RCX: 00007fd63f1a7757 [ 1429.195288] RDX: 00007ffe53bbe850 RSI: 00000000c0406481 RDI: 000000000000000f [ 1429.195289] RBP: 00000000027e3cd8 R08: 0000000000000000 R09: 00000000027f8b00 [ 1429.195290] R10: 00000000027f8710 R11: 0000000000000246 R12: 00000000027e3370 [ 1429.195290] R13: 00000000027e3cd0 R14: 00000000027e3680 R15: 00000000ffffffea My HW: Lenovo T460p > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06) > 02:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2) $ rpm -qa | grep -e 'kernel-[0-9]' -e xorg- > xorg-x11-utils-7.5-21.fc24.x86_64 > xorg-x11-server-Xwayland-1.19.0-3.fc26.x86_64 > xorg-x11-server-utils-7.7-20.fc26.x86_64 > kernel-4.10.0-0.rc2.git0.2.fc26.x86_64 > xorg-x11-xkb-utils-7.7-17.fc24.x86_64 > xorg-x11-drv-intel-2.99.917-26.20160929.fc26.x86_64 > kernel-4.10.0-0.rc2.git2.1.fc26.x86_64 > xorg-x11-xauth-1.0.9-5.fc24.x86_64 > xorg-x11-server-Xorg-1.19.0-3.fc26.x86_64 > xorg-x11-drv-nouveau-1.0.13-1.fc26.x86_64 > xorg-x11-font-utils-7.5-32.fc26.x86_64 > xorg-x11-resutils-7.5-13.fc24.x86_64 > xorg-x11-server-common-1.19.0-3.fc26.x86_64 > xorg-x11-xinit-1.3.4-13.fc26.x86_64 > xorg-x11-drv-evdev-2.10.4-1.fc26.x86_64 > xorg-x11-fonts-ISO8859-1-100dpi-7.5-16.fc24.noarch I am using sway WM if it can be relevant: > sway-0.11-4.fc26.x86_64 Let me know if you need any additional info, I'll keep an eye on possible recidivism. I haven't seen this before (few past hours actually), perhaps it may be attributed either to switching to updated kernel (both version stated) or to switching from awesome/X11 to sway/Wayland.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
I can reproduce this bug reliably on up-to-date Fedora 27. The bug happens with the kernel 4.13.3-300.fc27.x86_64. It doesn't happen with the self-compiled Linux 4.14-rc1 or 4.14-rc2. My system is a completely up-to-date Fedora 27 with updates and updates-testing repositories installed. I ran "dnf install 'Fedora Workstation'" is install all standard components. GNOME is used, no other desktop environments are installed. The system is Dell Precision 7510 with a dock. Two monitors, a keyboard and a mouse are connected to the dock. The laptop has Intel graphics for the internal monitor and NVIDIA for the external monitors. No non-free drivers are used. ====================================================== WARNING: possible circular locking dependency detected 4.13.3-300.fc27.x86_64 #1 Not tainted ------------------------------------------------------ Xorg/1032 is trying to acquire lock: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffc03c4dfa>] drm_gem_object_put_unlocked+0xa/0xb0 [drm] but task is already holding lock: (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc04cccc2>] validate_init.isra.5+0x202/0x740 [nouveau] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (reservation_ww_class_mutex){+.+.+.}: lock_acquire+0xa3/0x1f0 __ww_mutex_lock.constprop.9+0xa1/0x10c0 ww_mutex_lock+0x5e/0x70 i915_gem_object_set_tiling+0x118/0x330 [i915] i915_gem_set_tiling_ioctl+0x1b4/0x350 [i915] drm_ioctl_kernel+0x5d/0xb0 [drm] drm_ioctl+0x31b/0x3d0 [drm] do_vfs_ioctl+0xa6/0x6c0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x1f/0xbe -> #0 (&dev->struct_mutex){+.+.+.}: __lock_acquire+0x1367/0x13b0 lock_acquire+0xa3/0x1f0 drm_gem_object_put_unlocked+0x3d/0xb0 [drm] validate_fini_no_ticket+0xf5/0x130 [nouveau] nouveau_gem_ioctl_pushbuf+0x65f/0x10f0 [nouveau] drm_ioctl_kernel+0x5d/0xb0 [drm] drm_ioctl+0x31b/0x3d0 [drm] nouveau_drm_ioctl+0x72/0xc0 [nouveau] do_vfs_ioctl+0xa6/0x6c0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x1f/0xbe other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(reservation_ww_class_mutex); lock(&dev->struct_mutex); lock(reservation_ww_class_mutex); lock(&dev->struct_mutex); *** DEADLOCK *** 3 locks held by Xorg/1032: #0: (&cli->mutex){+.+.+.}, at: [<ffffffffc04e3083>] nouveau_abi16_get+0x33/0x70 [nouveau] #1: (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffffc04cdc50>] nouveau_gem_ioctl_pushbuf+0x2c0/0x10f0 [nouveau] #2: (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc04cccc2>] validate_init.isra.5+0x202/0x740 [nouveau] stack backtrace: CPU: 7 PID: 1032 Comm: Xorg Not tainted 4.13.3-300.fc27.x86_64 #1 Hardware name: Dell Inc. Precision 7510/0692Y5, BIOS 1.12.4 05/12/2017 Call Trace: dump_stack+0x8e/0xd6 print_circular_bug+0x1b6/0x210 __lock_acquire+0x1367/0x13b0 ? find_held_lock+0x3c/0xb0 lock_acquire+0xa3/0x1f0 ? lock_acquire+0xa3/0x1f0 ? drm_gem_object_put_unlocked+0xa/0xb0 [drm] ? __mutex_unlock_slowpath+0x52/0x2f0 drm_gem_object_put_unlocked+0x3d/0xb0 [drm] ? drm_gem_object_put_unlocked+0xa/0xb0 [drm] validate_fini_no_ticket+0xf5/0x130 [nouveau] nouveau_gem_ioctl_pushbuf+0x65f/0x10f0 [nouveau] ? nouveau_gem_ioctl_new+0x140/0x140 [nouveau] drm_ioctl_kernel+0x5d/0xb0 [drm] ? drm_ioctl_kernel+0x5d/0xb0 [drm] drm_ioctl+0x31b/0x3d0 [drm] ? nouveau_gem_ioctl_new+0x140/0x140 [nouveau] ? trace_hardirqs_on+0xd/0x10 nouveau_drm_ioctl+0x72/0xc0 [nouveau] do_vfs_ioctl+0xa6/0x6c0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x7f20d037f0d7 RSP: 002b:00007ffd3b9b7998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000e4a3d0 RCX: 00007f20d037f0d7 RDX: 00007ffd3b9b7a00 RSI: 00000000c0406481 RDI: 0000000000000010 RBP: 0000000000e41670 R08: 0000000000000000 R09: 0000000000e42400 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000e417b0 R13: 0000000000e41da0 R14: 0000000000e4a3d0 R15: 0000000000e41da0
Oh this is fun, both i915 and nouveau are involved here. This is probably best reported upstream at https://bugs.freedesktop.org/ . I'm going to move the component to the nouveau graphics package for better tracking in the meantime.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 EOL if it remains open with a Fedora 'version' of '27'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.