You are not logged in.
What happens: Screen freeze, followed by black screen. Switching to different tty (CTLR+ALT+F2 etc) has no effect, neither has terminating x via kb shortcut (Option "XkbOptions" "terminate:ctrl_alt_bksp").
Pressing the power button once has no effect either, only forced shut off by holding the power button works. This is why I suspect it's not just the Xserver but actually something in the kernels driver stack that crashes.
When it happens: Most consistently when using blender, displaying some mesh with a bunch of polygons and then moving the camera for a few seconds. With moderately high poly meshes it seems to happen faster (eg 100k+ faces).
But it has also happend while playing ioqake3, which is definitely not taxing or high-poly.
I had a similar crash (not black screen but garbled noise) with mpv some weeks ago, but that seemed resolved once I turned vaapi hardware accel off, so I don't assume it's the same issue, but I might be wrong, of course.
Note that I can leave blender open, displaying the scene the whole night without it crashing, but moving the camera for a few seconds consistently triggers a crash no matter how long blender has been running.
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
[...]
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280]
Subsystem: Micro-Star International Co., Ltd. [MSI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280]
Kernel driver in use: radeon
Kernel modules: radeon, amdgpu
[...]
No user config for video present in /etc/X11/xorg.conf.d/.
Packages: mesa 17.3.3-2, xf86-video-ati 1:7.10.0-1, linux 4.15.2-2
However, this has been happening since I've started using blender in december, so at least since linux 4.14.9-1, mesa 17.3.1-2. And blender is the only application where I can trigger it consistently.
Other 3D applications don't seem to be affected, I've been playing Divinity Original Sin regularly for several months without any such issue.
There are no entries for the time of crash in journalctl --boot -1 or ~/.local/share/xorg/Xorg.0.log.old.
coredump list also has nothing from the past days (last crash happened this morning).
Any suggestions what to try next would be appreciated. In the mean time, I'll try switching between KMS/xf86-video-{ati/amdpu}, turn off accel and other things mentioned in https://bbs.archlinux.org/viewtopic.php?id=229332
Last edited by lamarpavel (2018-02-11 10:40:37)
Offline
Some progress made:
I've created /etc/X11/xorg.conf.d/20-radeon.conf and set DRI explicitly to "2" and then to "3" (confirmed by Xorg.0.log).
Crashes occur just the same.
With "AccelMethod" set to "EXA", the crash occurs but I also have some graphics glitches (indicating that EXA was not used by default before).
Finally, with "Accel" set to "off" I am no longer able to reproduce the crash, but the performance has dropped significantly.
I'd say the rendering times have at least quadrupled.
On my laptop with integrated GPU (i5, 2d gen) acceleration is turned on (default glamor: OpenGL accelerated X.org driver based) without any crashes occuring.
I'll do some more research what this could mean, any help is still very much appreciated.
Offline
Alright, the problem seems to be with radeon + xf86-video-ati and using acceleration (both glamor and EXA). I have now switched to the amdgpu kernel driver as well as xf86-video-amdgpu and can no longer reproduce the crash even though glamor is being used for acceleration.
The performance is about as good as with radeon+glamor, but the crashes are gone. So I guess that solves it for me unless I discover that other programs are having problems with the amdgpu driver.
Just for the record, I am using no desktop environment and bspwm as window manager without compositor. I hope the information provided in this thread is helpful to others in the future.
Offline
you can use directly "modesetting" instead of "radeon" in /etc/X11/xorg.conf.d/20-radeon.conf
Driver "modesetting"Offline