GNOME Bugzilla – Bug 768308
Wayland Gnome session hangs if dedicated GPU is switched off
Last modified: 2021-07-05 13:51:44 UTC
I have two graphics cards. One integrated intel GPU and a dedicated NVIDIA GPU. If I run a wayland gnome session while the dedicated GPU is switched off, then the system freezes randomly on certain actions as triggering the shell overview (SUPER KEY) and starting a program. Output of 'lspci | grep -E "VGA|3D"': 00:02.0 VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 06) 01:00.0 3D controller: NVIDIA Corporation GM204M [GeForce GTX 970M] (rev a1) Hope we can fix this!
This problem seams to be related to the kernel. https://bugs.freedesktop.org/show_bug.cgi?id=9678 Quote: "After hours of debugging I made following experience: Xorg and Wayland both have problems when the dedicated GPU is switched off and no kernel module is loaded. However if the nouveau module with the proprietary firmware is loaded, then the problem seams to be fixed. The latest nouveau module handles powersaving and switches the GPU automatically off. This is a good workaround, but prevents from using the proprietary nvidia modules for bumblebee..."
(In reply to Roland from comment #1) > This problem seams to be related to the kernel. > > https://bugs.freedesktop.org/show_bug.cgi?id=9678 You're missing the last digit in your link: https://bugs.freedesktop.org/show_bug.cgi?id=96780
Thanks for correcting the link. I made some more testing and I still have problems, even with the nouveau driver loaded. It is possible, that the freeze bug sits inside the Gnome compositor... Gnome freezes always during super action followed by starting a program. Any hints how to debug this? I'll try to check if this freezes occur also in other window managers / desktop environments...
(In reply to Roland from comment #3) > ... Any hints how to debug this? > I'll try to check if this freezes occur also in other window managers / > desktop environments... If you have access to another computer you could make sure to have debug symbols, then attach gdb to the running process. After the compositor has frozen, use the other computer to break gdb and see where it is waiting. It may either be in some GMainLoop idle function, or further up some call stack. Another thing you could do is run gnome-shell with the following environmental variables set: MUTTER_DEBUG=1 MUTTER_VERBOSE=1 CLUTTER_DEBUG=all
Until gnome-session 3.24.1 I worked around this bug by having bumblebeed disabled, so the discrete card is left switched on and once gnome is up, I did a systemctl start bumblebeed, which let bbswitch switch the card off. For now, I've switched to xfce running on X and I have this in my xorg.conf: https://paste.debian.net/hidden/71df05a1/ This at least keeps X from trying to access the nvidia card using AutoAdd, as it seems. However, having exec gnome-session in my ~/.xinitrc , gnome-session or something that is started by gnome-session causes the nvidia driver to be loaded again. If bumblebeed has started before running gnome-session, my system hangs. Starting it afterwards works, but won't switch off the discrete nvidia card. I'm not sure what the intention behind implementing GPU switching is when it seems to be done only halfway. Or am I missing some switching magic that is new in gnome?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.