Frequent display freezes with nouveau after update to Leap 15.0

English Hardware
#1

I recently upgraded to Leap 15.0 from Leap 42.3, using the GNOME shell. With Leap 42.3, I would occasionally have graphics freezes by nouveau, but only when playing h264 video:

  ###.######] nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon

But now, with Leap 15.0, nouveau is crashing (and thus freezing the display) much more frequently. As I understand it, the move to Wayland from Xorg is the largest different between 15.0 and 42.3, so I would assume the problem lies between nouveau and Wayland. Running GNOME on Wayland, I hit crashes within minutes, but even running GNOME on Xorg (understanding that Wayland is emulating Xorg with XWayland), I am hitting these display freezes almost daily. And, though I can access the system through ssh and other means, I cannot restore the display without a hard reset of the machine.

Occasionally, I will be able to enter the system’s console (Ctrl+Alt+F1), mainly if I manage to kill the display-manager service and see many lines similar to the following in dmesg:

nouveau 0000:01:00.0: fifo: INTR 00800000
nouveau 0000:01:00.0: fifo: INTR 01000000: 00000005
nouveau 0000:01:00.0: fifo: INTR 01000000: 00000005
nouveau 0000:01:00.0: fifo: INTR 01000000: 00000005
nouveau 0000:01:00.0: fifo: INTR 01000000: 00000005
nouveau 0000:01:00.0: Failed to idle channel 2.

On multiple occasions, I have hit this error by opening a new tab in Firefox and entering an address, and then quickly using Alt+Tab to switch to a different application while I was for the Firefox tab to load. But, the display will freeze with the Alt+Tab panel on the screen.

As I search for solutions, I see Fedora bug reports matching my symptoms marked as closed, and feel a sense of hope until I see that they seem to ignore problems until they can close the bugs due to version End-of-Life (like this one that seems to match my experience to a T).

I would really prefer to use Open-Source drivers and not venture into the nVidia proprietary drivers for my card, so I’m really hoping I can fix this error.

# lspci -nnk | grep -Ei -A 3 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119M [NVS 4200M] [10de:1056] (rev a1)
        Subsystem: Dell Device [1028:0494]
        Kernel driver in use: nouveau
        Kernel modules: nouveau
#2

Try the alternate FOSS driver. Either specify “modesetting” as the driver in /etc/X11/xorg.conf.d/50-device.conf or /etc/X11/xorg.conf, or uninstall xf86-video-nouveau.

#3 
su -
update-alternatives --config default-displaymanager

Choose LightDM, try that.

#4

Uninstalling xf86-video-nouveau, I still see nouveau as my lspci output:

# lspci -nnk | grep -Ei -A 3 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119M [NVS 4200M] [10de:1056] (rev a1)
        Subsystem: Dell Device [1028:0494]
        Kernel driver in use: nouveau
        Kernel modules: nouveau

Which FOSS driver are you referencing? Is setting modesetting as the driver the same as setting nomodeset in the kernel parameters?

#5

You’re getting confused between the kernel driver and the user-space Xorg driver which this package provides. The recommendation to remove the Xorg nouveau driver will cause the modesetting driver to be loaded. You can examine the Xorg.0.log to see what is being loaded/unloaded eg

cat /var/log/Xorg.0.log|grep -i load

or just use inxi (you may need to install it first)

inxi -G

Which FOSS driver are you referencing? Is setting modesetting as the driver the same as setting nomodeset in the kernel parameters?

The modesetting driver (modesetting_drv.so) is included as part of the Xorg server (xorg-x11-server package), and supports all graphics hardware where a KMS driver is available (including the nouveau kernel driver).

#6 
inxi -Gxx

run from within X (operable from without X, but with less complete output), should make it clearer (as opposed to lspci) that there is not one single nouveau driver. There is a (low level) kernel driver built into the kernel that is named “nouveau”, and there is one X driver also named “nouveau”. The former is not optional, as in provided by a separate package or module, but can be disabled by using either nomodeset or nouveau.modeset=0 on the kernel cmdline. The latter “nouveau” is optional, provided by xf86-video-nouveau, and used only by X. The other X driver option is named “modesetting”, but it is provided from within the X server rather than by a separate package. Disabling KMS (kernel mode setting) via the kernel cmdline disables all all modesetting drivers (kernel, X modesetting, X nouveau, X intel, X amdgpu, X radeon, etc.). Choice of X driver can be made affirmatively via xorg.conf*. If not so made, the X nouveau driver will be used if supported and installed. Otherwise, the modesetting driver will be used, if supported. Really old nvidia gfx are stuck with inferior driver choices, nv, fbdev and/or vesa, provided by their respective xf86-video-* packages.

#7

But has it impacted $SUBJECT? If not, it may be that only a proprietary (NVidia) X driver would comprise a current solution in 15.0.

By “upgrade”, did you mean a literal upgrade, or did you switch from 42.3 to 15.0 via fresh installation? Either way, maybe something else is going on. Was a switch made from EXT4 / to BTRFS (fresh installation)? Is freespace low or logging bloated (upgrade -> lots of and/or giant files in /var/log/, particularly journal/*/)? Is something causing overheating, accumulated dust on CPU cooler or GPU cooler, or dead GPU fan? Is power supply a quality part of ample capacity, or maybe getting tired and marginal? Is whatever Gnome uses to cache personal files, or something else, busy in the background? Is free RAM adequate? Has RAM ever been tested?

#8

Thank you for persisting with me. I uninstalled xf86-video-nouveau and put the following in my /etc/X11/xorg.conf.d/50-device.conf file:

Section "Device"
  Identifier "Default Device"
  Driver "modesetting"
EndSection

But still it seems X is finding nouveau from somewhere:

# inxi -Gxx
Graphics:  Card: NVIDIA GF119M [NVS 4200M] bus-ID: 01:00.0 chip-ID: 10de:1056
           Display Server: x11 (X.Org 1.19.6 )
           drivers: nouveau (unloaded: modesetting,fbdev,vesa)
           Resolution: 1920x1080@59.91hz
           OpenGL: renderer: NVD9
           version: 4.3 Mesa 18.0.2 (compat-v: 3.0) Direct Render: Yes

So far, crashes have still been happening, especially if I try GNOME on Wayland, rather than GNOME on Xorg (XWayland). But, I keep asking questions because I’m not sure I’ve successfully tried the modesetting drivers yet.

#9

By upgrade, I mean a zypper dup with the new 15.0 repositories in place (OSS and Update repositories only). I did not switch filesystems and I have plenty of free space (20% usage).

The fans don’t make much noise and I have plenty of RAM, though I haven’t tested it. But, these problems would probably lead to an unresponsive system, a true system crash. In this issue, where the display crashes, I can still access my machine through SSH.

#10

Did you restart X or reboot after removing xf86-video-nouveau? What you get consequently should resemble what follows:

$ rpm -qa | grep veau
libdrm_nouveau2-2.4.91-lp150.1.2.x86_64
$ inxi -V | head -n1
inxi 2.3.40-00 (2017-09-21)
$ inxi -Gxx
Graphics:  Card: NVIDIA GT218 [GeForce 210] bus-ID: 01:00.0 chip-ID: 10de:0a65
           Display Server: X.Org 1.19.6 drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1200@59.95hz
           OpenGL: renderer: llvmpipe (LLVM 5.0, 128 bits)
           version: 3.3 Mesa 18.0.2 (compat-v: 3.0) Direct Render: Yes
$ rpm -qa | grep veau
libdrm_nouveau2-2.4.91-lp150.1.2.x86_64
$ inxi -V | head -n1
inxi 3.0.27-00 (2018-10-14)
$ inxi -Gxx
Graphics:  Device-1: NVIDIA GT218 [GeForce 210] vendor: eVga.com. driver: nouveau v: kernel
           bus ID: 01:00.0 chip ID: 10de:0a65
           Display: server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa
           alternate: nouveau,nv,nvidia resolution: 1920x1200~60Hz
           OpenGL: renderer: llvmpipe (LLVM 5.0 128 bits) v: 3.3 Mesa 18.0.2 compat-v: 3.0
           direct render: Yes
$

inxi 3.0.27 is the more informative Tumbleweed version.

#11

inxi 3.0.27 is the more informative Tumbleweed version.

FWIW, it is possible to update xinxi with a simple

sudo xinxi -U

I’ve just done that…now using version 3.0.27-00 (2018-10-14)

#12

I did restart. I had Mesa-dri-nouveau in my rqm list, so I removed that as well (and then restarted again). But, inxi (now 3.0.27-00) still shows my X11 driver as nouveau.

# rpm -qa | grep veau
libdrm_nouveau2-2.4.91-lp150.1.2.x86_64
libdrm_nouveau2-32bit-2.4.91-lp150.1.2.x86_64
# inxi -Gxx
Graphics:
  Device-1: NVIDIA GF119M [NVS 4200M] vendor: Dell driver: nouveau v: kernel 
  bus ID: 01:00.0 chip ID: 10de:1056 
  Display: x11 server: X.Org 1.19.6 driver: nouveau unloaded: fbdev,modesetting,vesa 
  alternate: nv,nvidia compositor: gnome-shell resolution: 1920x1080~60Hz 
  OpenGL: renderer: llvmpipe (LLVM 5.0 256 bits) v: 3.3 Mesa 18.0.2 compat-v: 3.0 
  direct render: Yes
#13

Though my system is responding slowly, like I was running in software rendering. I searched for nouveau in my /etc/ directory and found nothing (outside of French language strings).

#14

Can you please also post the output of the following?

 cat /var/log/Xorg.0.log |grep -i load
#15

I can’t imagine how the output of your rpm -qa | grep veau and inxi -Gxx commands can be reconciled. The nouveau X driver is provided by the (not installed) package xf96-video-nouveau. :dont-know:

Please show us a complete Xorg.0.log.

#16

palswim, is your / filesystem BTRFS? I’d like to see the mount stats and your partitioning if it is.

#17

I think what’s shown is the nouveau module that’s in the initrd. Try running


dracut -f

then reboot.

#18

… and please continue to ignore my suggestion. I enjoy spending time trying to help and being ignored.:slight_smile:

#19

That’s not an inclusion in an initrd that I would expect. On three different installations that use xf86-video-nouveau I just tried

lsinitrd /boot/initrd | grep -i veau

and got null output from each.

#20

Agreed - the Xorg driver is a user-space driver anyway, and loaded by Xorg as required.