Reading the title, you’ve probably already identified three points of failure, but first let me explain:
I had a Leap 42.3 system running GNOME on GDM and everything was running smoothly, including the situation I will describe. I made a fateful (and ill-advised) decision to upgrade to Leap 15.0 and have been fighting my system ever since. I moved to XFCE from GNOME to avoid the random crashes, but I have been able to make my machine crash consistently with a particular sequence of actions (in GNOME or XFCE):
Log in to X environment
Start WINE application (Neverwinter Nights, nmwain.exe
) 1. Start the Hordes of the Underdark campaign and create a character
As soon as the character creation finishes, the application plays a Bink video, which causes the display to freeze. It does not bring down the entire system (e.g. I can SSH into the system), but I can no longer use the display or input devices until I’ve rebooted.
[10929.235440] nouveau 0000:01:00.0: gr: TRAP ch 6 [001fb88000 nwmain.exe]
[10929.235461] nouveau 0000:01:00.0: gr: GPC0/PROP trap: 00000080 [ZETA_STORAGE_TYPE_MISMATCH] x = 0, y = 0, format = 0, storage type = 17
[10929.235486] nouveau 0000:01:00.0: fifo: write fault at 0005c4b000 engine 00 [PGRAPH] client 0f [GPC0/PROP] reason 02 [PAGE_NOT_PRESENT] on channel 6 [001fb88000 nwmain.exe]
[10929.235498] nouveau 0000:01:00.0: fifo: gr engine fault on channel 6, recovering…
[10929.235899] nouveau 0000:01:00.0: nwmain.exe: channel 6 killed!
So, why identify Nouveau and not WINE or the application itself? This is a Nouveau (or other kernel-level) issue because I cannot recover by ending the session or anything but rebooting. If the application crashed, I would blame WINE or the application. But, the same application and portion of playing the video works flawlessly on Leap 42.3. That everything worked in Leap 42.3 also led me to report this issue here rather than the freedesktop.org Bugzilla.
I was able to reproduce this behavior on a fresh install using Nouveau on different hardware (but obviously still an NVidia card) as well.
Can you reproduce the crash starting Wine in an IceWM session too?
Even though dmesg seems to point to the nouveau kernel driver, I’d give the other FOSS X driver a chance. Easiest way is to uninstall xf86-video-nouveau and restart X or reboot. The “other” FOSS X driver shows up as modeset(0) in Xorg.0.log. It’s been part of the X server package since server 1.17.x.
The display does not crash (so far) after uninstalling Mesa-dri-nouveau (and Mesa-dri-nouveau-32bit), though I did have to reinstall Mesa-dri to hook up OpenGL correctly (zypper in -f Mesa-dri Mesa-dri-32bit).
# zypper se nouveau
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
| Mesa-dri-nouveau | Mesa DRI plug-in for 3D acceleration via Nouveau | package
| Mesa-dri-nouveau-32bit | Mesa DRI plug-in for 3D acceleration via Nouveau | package
| libXvMC_nouveau | XVMC state tracker for Nouveau | package
| libXvMC_nouveau-32bit | XVMC state tracker for Nouveau | package
i+ | libdrm_nouveau2 | Userspace interface for Kernel DRM services for -> | package
i+ | libdrm_nouveau2-32bit | Userspace interface for Kernel DRM services for -> | package
i | libvdpau_nouveau | XVMC state tracker for Nouveau | package
| libvdpau_nouveau-32bit | XVMC state tracker for Nouveau | package
| xf86-video-nouveau | Accelerated Open Source driver for nVidia cards | package
Yes, I think so. The result is supposed to be that much of the OpenGL support is done is software, instead of using the hardware features of the card. So you won’t get the extra speed. But that’s still better than having it crash.
You might need to lock mesa-dri-nouveau to prevent it from being reinstalled, though I think you would be asked first.
I had no idea: 1: inxi was ever this broken, or 2: it is possible for X to used a not installed xf86-video-nouveau driver instead of modesetting. Development of inxi, which is just a script, has had many increments since the ancient version in the 15.0 release. Please try a newer version. TW’s 3.0.29 package can be installed by downloading from a mirror then upgrading with rpm, but if you do it this way, it’s subject to possibly being downgraded via YaST or zypper if you don’t lock it. The inxi -U switch is supposed to upgrade to the latest version, but doesn’t always work, for various reasons shown when tried. I always try -U first. Here is expected output from an older NVidia:
# grep RETT /etc/os-release
PRETTY_NAME="openSUSE Leap 15.0"
# zypper se -s o-nouv
S | Name | Type | Version | Arch | Repository
| xf86-video-nouveau | package | 1.0.15-lp150.1.9 | x86_64 | OSS
# inxi -V | head -n1
inxi 3.0.29-00 (2018-12-10)
# 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
OpenGL: renderer: llvmpipe (LLVM 5.0 128 bits) v: 3.3 Mesa 18.0.2 compat-v: 3.0 direct render: Yes