SUMMARY After a graphics reset, either a laptop screen or an external monitor attached to it turn black, until the system is forcefully rebooted. STEPS TO REPRODUCE 1. Use plasma with a relatively high graphics load (e.g. fast switching between multiple windows, mostly some graphics related task in Firefox or forks) on two screens (laptop and one external screen). 2. One of both screen blackouts and a notification pops up, "Desktop effects were restarted due to a graphics reset" 3. Screen that blacked out doesn't "wake up" any more and remains blacked out. Soon after, the screen looses the signal and turn in standby mode. 4. The laptop can be used normally until the next graphics reset, causing the second screen to irrevocably turn black. Alternatively, disabling the screen in the "Display configuration" causes the system to immediately freeze. Audio is still being played back, but the system is completely unresponsive or heavily delayed (in the realm of minutes). 5. Only a forced reboot solves the issue. EXPECTED RESULT After a graphical reset, the screen should return to its previous state and operate normally. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux 6.14.3-arch1-1 (64-bit) KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.13.0 Qt Version: 6.9.0 ADDITIONAL INFORMATION This only happens when an external monitor is connected to my laptop. Using my laptop screen only doesn't lead to the permanently blacked out screen. One or two months ago, this "graphics reset" did never occur one, not even under high graphical and CPU load. It seems a more recent update introduced this "feature" I don't really understand in the first place, as I could not find any information related to this. My laptop has pretty recent hardware (2024 Q2) and features an OLED screen. I could see that being part of the issue. BACKTRACE Generated with gdb with following command from the KWin/Debugging guide: echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope sudo gdb -pid $(pidof kwin_wayland) -batch -ex "set logging file kwin_wayland.gdb" -ex "set logging enabled on" -ex "continue" -ex "thread apply all backtrace" -ex "quit" https://cryptpad.fr/code/#/2/code/view/eVZeidlYQb-X3RFqw2Cj0zZna6iVBYs1qZg78m+Y3-Y/embed/
Hi - just for reference, the number of unknown functions in that backtrace might indicate that installing debugging packages would help produce more useful backtraces: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Install_debugging_packages
I happened again two or three times while using LibreWolf and Zen Browser (Firefox forks). Maybe it is an upstream issue. Thanks for the info @John Kizer
Please attach the output of drm_info while the external monitor is connected. > One or two months ago, this "graphics reset" did never occur one, not even under high graphical and CPU load. It seems a more recent update introduced this "feature" I don't really understand in the first place, as I could not find any information related to this. Graphics resets are usually caused by driver bugs, and can start happening after a driver update.
Link to the drm_info output: https://cryptpad.fr/code/#/2/code/view/OjIavqKDKNjahR3wft7dnK5eCi9TbbNqKsRv5kfB85c/embed/ It's incredibly long, but I did not know what to keep/what you are looking for @Zamundaaa.
hmm, so this is a single GPU system only, GPU reset recovery should work properly there. After the issue happens the next time, please attach the output of > journalctl --user-unit plasma-kwin_wayland --boot 0 and > journalctl -k --boot 0 Also, what happens if you unplug the screen while it's not receiving a signal?
(In reply to Zamundaaa from comment #5) Bug happened again, however for the first time, the second screen recovered the signal after a short blackout. It could be either a "fluke" or a system update fixed this problem (aside from unrelated packages, I only updated the kernel to 6.14.5-arch1-1). In the first dump, an AMD driver causing an issue is being mentioned, so I don't know. In any case, I'll report back whether I can reproduce the issue again or not. > > journalctl --user-unit plasma-kwin_wayland --boot 0 Dump: https://cryptpad.fr/code/#/2/code/view/85-hDqatpQawFwIxXzH8qKubmpgEbGm6h0T5XptB9h0/embed/ > > journalctl -k --boot 0 Dump: https://cryptpad.fr/code/#/2/code/view/eAQCKNaXjaP9RbQU4IXiILd25tws3YGoI4Sd121sj08/embed/ In the above one, "zen-bin" refers to the Zen Browser (fork of Firefox, previously happened with LibreWolf as well), build from the Arch User Repo "zen-browser-bin" package. > Also, what happens if you unplug the screen while it's not receiving a signal? Until now, turning the screen off, unplugging and plugging it in again does not recover the signal. Additional trace: echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope sudo gdb -pid $(pidof kwin_wayland) -batch -ex "set logging file kwin_wayland.gdb" -ex "set logging enabled on" -ex "continue" -ex "thread apply all backtrace" -ex "quit" https://cryptpad.fr/code/#/2/code/view/qizhMoeFiEzD2ca+dzm2gYO1cSJVqo8q8SQzRzIKhVI/embed/ I installed some debugging dependencies, there are still some libraries I could not find/install, so I doubt this trace provides any meaningful information.
Hi kde.vacant701@passmail.net - just checking, did you mean to indicate that this issue is resolved? On that last comment, the main status was left as "NEEDSINFO", but the resolution was "FIXED", so I just wanted to make sure which was correct :-)
(In reply to John Kizer from comment #7) > Hi kde.vacant701@passmail.net - just checking, did you mean to indicate that > this issue is resolved? On that last comment, the main status was left as > "NEEDSINFO", but the resolution was "FIXED", so I just wanted to make sure > which was correct :-) My bad, I did not intend on doing that. For now, I don't consider it to be resolved.
It just happened again, and the second screen recovered again from the blackout. Same trace logs, the "pageflip" bug originiating in the AMD graphic driver is being mentioned again. Checking the issue tracker of the named project (https://gitlab.freedesktop.org/drm/amd/), a lot of reports about "pageflip" have been opened. Therefore, the bug is likely due to the AMD drivers as already suggested by @Zamundaaa. It makes even more sense, as I remember also updating the mesa packages a few days ago. I think the bug can be marked as resolved now.