On Fedora 27 GNOME/Wayland desktop, I can reliably reproduce the desktop freezing when grabbing the border of a Firefox window with the mouse and dragging to resize. (Where Firefox brings Xwayland into the mix, IIUC. The only way I found to make the machine responsive again is to ssh into it and kill -9 the Xwayland processes, which gets me back to the GNOME login screen.) journalctl says: > Dec 12 11:24:42 alpha kernel: nouveau 0000:02:00.0: gr: TRAP ch 16 [003f49a000 Xwayland[27222]] > Dec 12 11:24:42 alpha kernel: nouveau 0000:02:00.0: gr: GPC0/TPC0/TEX: 80000049 > Dec 12 11:24:42 alpha kernel: nouveau 0000:02:00.0: gr: GPC0/TPC1/TEX: 80000049 > Dec 12 11:24:42 alpha kernel: nouveau 0000:02:00.0: fifo: read fault at 0001c7e000 engine 00 [PGRAPH] client 04 [GPC0/] reason 02 [PAGE_NOT_PRESENT] on channel 16 [003f49a000 Xwayland[27222]] > Dec 12 11:24:42 alpha kernel: nouveau 0000:02:00.0: fifo: gr engine fault on channel 16, recovering... > Dec 12 11:24:42 alpha kernel: nouveau 0000:02:00.0: Xwayland[27222]: channel 16 killed! The GPU is "VGA compatible controller: NVIDIA Corporation GF108GL [Quadro 600] (rev a1)" according to lspci. Reproducible with kernel 4.14.3-300.fc27.x86_64, but not reproducible with 4.13.13-300.fc27.x86_64. Also not reproducible with neither (from a VT) running `weston --xwayland` nor `weston --use-pixman --xwayland`.
This is just a "me too" for this issue: also a Fedora 27 GNOME/Wayland desktop, and resizing a Firefox window, and the freeze can be quickly and reliably reproduced. Video: NVIDIA Corporation GF108M [NVS 5400M] (rev a1) Kernel: 4.14.5-300.fc27.x86_64 (and a number of earlier versions)
Another “me too”. Sorry if this is redunant. On Arch Linux with: > Linux emi 4.14.6-1-ARCH #1 SMP PREEMPT Thu Dec 14 21:26:16 UTC 2017 x86_64 GNU/Linux Output from `lspci`: > 01:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1) (prog-if 00 [VGA controller]) > Subsystem: ASUSTeK Computer Inc. GM204 [GeForce GTX 970] > Flags: bus master, fast devsel, latency 0, IRQ 127 > Memory at f6000000 (32-bit, non-prefetchable) [size=16M] > Memory at 2fe0000000 (64-bit, prefetchable) [size=256M] > Memory at 2ff0000000 (64-bit, prefetchable) [size=32M] > I/O ports at e000 [size=128] > Expansion ROM at 000c0000 [disabled] [size=128K] > Capabilities: <access denied> > Kernel driver in use: nouveau > Kernel modules: nouveau Output from `dmesg`: > [ 5116.198746] nouveau 0000:01:00.0: gr: TRAP ch 3 [103f3eb000 Xwayland[1034]] > [ 5116.198756] nouveau 0000:01:00.0: gr: GPC0/TPC0/TEX: 80000041 > [ 5116.198760] nouveau 0000:01:00.0: gr: GPC0/TPC1/TEX: 80000041 > [ 5116.198764] nouveau 0000:01:00.0: gr: GPC0/TPC2/TEX: 80000041 > [ 5116.198770] nouveau 0000:01:00.0: gr: GPC2/TPC0/TEX: 80000041 > [ 5116.198774] nouveau 0000:01:00.0: gr: GPC2/TPC1/TEX: 80000000 > [ 5116.198782] nouveau 0000:01:00.0: fifo: read fault at 00075d7000 engine 00 [GR] client 15 [GPC0/PE_4] reason 02 [PTE] on channel 3 [103f3eb000 Xwayland[1034]] > [ 5116.198788] nouveau 0000:01:00.0: fifo: channel 3: killed > [ 5116.198789] nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery > [ 5116.198792] nouveau 0000:01:00.0: fifo: engine 0: scheduled for recovery > [ 5116.198804] nouveau 0000:01:00.0: gr: TRAP ch 3 [103f3eb000 Xwayland[1034]] > [ 5116.198810] nouveau 0000:01:00.0: gr: GPC1/TPC1/TEX: 80000041 > [ 5116.198816] nouveau 0000:01:00.0: gr: GPC3/TPC0/TEX: 80000000 > [ 5116.198820] nouveau 0000:01:00.0: gr: GPC3/TPC1/TEX: 80000000 > [ 5116.198824] nouveau 0000:01:00.0: gr: GPC3/TPC3/TEX: 80000041 > [ 5116.198835] nouveau 0000:01:00.0: gr: TRAP ch 3 [103f3eb000 Xwayland[1034]] > [ 5116.198842] nouveau 0000:01:00.0: gr: GPC1/TPC0/TEX: 80000000 > [ 5116.198846] nouveau 0000:01:00.0: gr: GPC1/TPC2/TEX: 80000041 > [ 5116.198848] nouveau 0000:01:00.0: Xwayland[1034]: channel 3 killed! > [ 5116.214208] nouveau 0000:01:00.0: fifo: write fault at 0000cec000 engine 05 [BAR2] client 08 [HOST_CPU_NB] reason 0d [REGION_VIOLATION] on channel -1 [103fefd000 unknown] After a few minutes, this also appears: > [ 5283.543441] INFO: task kworker/u16:0:6381 blocked for more than 120 seconds. > [ 5283.543450] Tainted: G C 4.14.6-1-ARCH #1 > [ 5283.543453] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 5283.543456] kworker/u16:0 D 0 6381 2 0x80000000 > [ 5283.543556] Workqueue: events_unbound nv50_disp_atomic_commit_work [nouveau] > [ 5283.543559] Call Trace: > [ 5283.543572] ? __schedule+0x290/0x890 > [ 5283.543580] ? __wake_up_common+0x6d/0x120 > [ 5283.543586] schedule+0x2f/0x90 > [ 5283.543591] schedule_timeout+0x208/0x390 > [ 5283.543636] ? nvkm_ioctl+0x100/0x240 [nouveau] > [ 5283.543644] ? dma_fence_default_wait+0x1cc/0x270 > [ 5283.543647] dma_fence_default_wait+0x1cc/0x270 > [ 5283.543652] ? dma_fence_release+0xa0/0xa0 > [ 5283.543657] dma_fence_wait_timeout+0x33/0x100 > [ 5283.543674] drm_atomic_helper_wait_for_fences+0x5d/0xc0 [drm_kms_helper] > [ 5283.543756] nv50_disp_atomic_commit_tail+0x55/0x3a70 [nouveau] > [ 5283.543766] process_one_work+0x1db/0x410 > [ 5283.543772] worker_thread+0x2b/0x3d0 > [ 5283.543777] ? process_one_work+0x410/0x410 > [ 5283.543781] kthread+0x118/0x130 > [ 5283.543785] ? kthread_create_on_node+0x70/0x70 > [ 5283.543789] ret_from_fork+0x25/0x30 and repeats every 120 seconds or so.
Gnome/wayland is buggy as hell. Do not blame the Nouveau driver. With any open source gpu driver, use Debian testing Xfce with Display Compositing enabled, Oibaf ppa latest ubuntu version and a latest custom kernel. For more inforamtion see: https://bugs.winehq.org/show_bug.cgi?id=43995
I can confirm that GNOME/Wayland/Nvidia crashes when resizing windows. Not only in Firefox but also in other apps. It's happening with Nouveau and Nvidia proprietary driver (my hardware is an Nvidia GeForce GTX 750 Ti) As a workaround, I switched back to Gnome/X11 and the desktop freezes are gone. Gnome/Wayland with Intel-CPU driver works fine. I guess Nvidia hardware and Wayland is not the best combination, hopefully it will become more stable soon.
Always fails (EVERY SINGLE TIME window is resized): journalctrl log of nouveau failure on resize FireFox window: Dec 31 08:16:06 US-D001.att.net kernel: nouveau 0000:03:00.0: Xwayland[5190]: channel 20 killed! Dec 31 08:16:06 US-D001.att.net kernel: nouveau 0000:03:00.0: fifo: gr engine fault on channel 20, recovering... Dec 31 08:16:06 US-D001.att.net kernel: nouveau 0000:03:00.0: fifo: read fault at 0002727000 engine 00 [PGRAPH] client 04 [GPC0/] reason 02 [PAGE_NOT_PRESENT] on channel 20 [003f3aa000 Xwayland[5190]] Dec 31 08:16:06 US-D001.att.net kernel: nouveau 0000:03:00.0: gr: GPC0/TPC1/TEX: 80000049 Dec 31 08:16:06 US-D001.att.net kernel: nouveau 0000:03:00.0: gr: GPC0/TPC0/TEX: 80000049 Dec 31 08:16:06 US-D001.att.net kernel: nouveau 0000:03:00.0: gr: TRAP ch 20 [003f3aa000 Xwayland[5190]] D
Hello, another me-too here. Arch Linux with Gnome+Wayland, Kernel 4.14.11-1-ARCH using the nouveau driver on a mid-2014 macbook pro (11,2). I'm using Firefox Nightly from the AUR ('firefox-nightly'), which is version 59.0a1, and client-side decorations in Firefox are turned on (so no separate GNOME title bar).
(In reply to Rylan from comment #6) > Hello, another me-too here. Arch Linux with Gnome+Wayland Some more information regarding this: 1. The issue is reproducible fairly consistently on my system, but sometimes I have to resize the firefox window upto 5 times (manually dragging window corner by about 20%) to reproduce the freeze. So far, I have only observed the freeze occurring when window is being expanded, it does not seem to occur when the windows is being decreased in size. 2. The freeze happens with both Firefox Nightly and stable Firefox, so client-side decorations (or some other Nightly-only feature) do not seem to be responsible. 3. I cannot reproduce this issue in any other application except Firefox...even Thunderbird (also by Mozilla) does not seem to be affected. 4. It does not seem to matter what page is being rendered by Firefox. The freeze occurs even when firefox is showing a blank page with no internet connection.
I experienced freezes by resizing gvim and riot as well.
Going to assign this to myself since I'm already looking at it (and can reproduce it reliably here).
patches available at https://patchwork.freedesktop.org/patch/199851/
(In reply to Lyude Paul from comment #10) > patches available at https://patchwork.freedesktop.org/patch/199851/ v2: https://patchwork.freedesktop.org/patch/199865/
The commit is in Linux 4.16. Is that issue solved for everyone experiencing the problem? ``` $ git log --oneline -1 5bffee867df7494ecd32c1e6ec4e8fc934c521b7 5bffee867df7 dma-buf: fix reservation_object_wait_timeout_rcu once more v2 $ git tag --contains 5bffee867df7494ecd32c1e6ec4e8fc934c521b7 v4.16 v4.16-rc1 v4.16-rc2 v4.16-rc3 v4.16-rc4 v4.16-rc5 v4.16-rc6 v4.16-rc7 v4.16.1 v4.16.10 v4.16.11 v4.16.12 v4.16.13 v4.16.14 v4.16.2 v4.16.3 v4.16.4 v4.16.5 v4.16.6 v4.16.7 v4.16.8 v4.16.9 v4.17 v4.17-rc1 v4.17-rc2 v4.17-rc3 v4.17-rc4 v4.17-rc5 v4.17-rc6 v4.17-rc7 v4.18-rc1 ```
(In reply to Paul Menzel from comment #12) > The commit is in Linux 4.16. Is that issue solved for everyone experiencing > the problem? I cannot confirm as I moved away from NVIDIA to AMD due to too many issues with NVIDIA.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/390.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.