SUMMARY As reported on a few forum posts in the Manjaro forum, on AMD Ryzen laptops the compositor prevents the PC to wake up from a suspend state. When suspending the machine with the compositor enabled, waking it up will result in a black screen without any possibility of user input (the PC looks totally frozen and the only way out is shutting it off with power button). A workaround so far is disabling the compositor before suspending the device, either manually or with a systemd service, but even like this it fails from time to time forcing an hard shutdown. STEPS TO REPRODUCE 1. Enable the compositor 2. Suspend the device 3. Wake up the device OBSERVED RESULT Black screen with no possibility of user input. EXPECTED RESULT Wake up the device. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro 18.1.5 KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66 Qt Version: 5.14 ADDITIONAL INFORMATION This issue has been around since I moved to KDE in September 2019, and I've found the same issues in older forum posts since end-2018. All my researches had Ryzen CPUs as common specs, I don't know if it might affect Intel devices.
Does this happen when another compositor is used?
(In reply to David Edmundson from comment #1) > Does this happen when another compositor is used? I've only tried XFWM and it didn't reproduce the problem. I've also tried to change the OpenGL version used by KWin from 3.1 to 2.0 but the problem persisted.
Can you switch VT via Ctrl+Alt+F# key combination and then check if XServer and/or KWin are running and restart KWin via DISPLAY=:0 kwin_x11? Also try it with Wayland session.
(In reply to Roman Gilg from comment #3) > Can you switch VT via Ctrl+Alt+F# key combination and then check if XServer > and/or KWin are running and restart KWin via DISPLAY=:0 kwin_x11? > > Also try it with Wayland session. The PC is completely unresponsive from user input. The screen backlight turns on, the power button LED and the keyboard too, but any kind of input is off. The key combination you suggested doesn't work with any F# key. I've tested Wayland and it works fine.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Requested info was provided.
This bug started to occur for me in the last week or so. --- Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 5.19.0-35-generic (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 62,7 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2 Product Name: X570 Extreme4
Created attachment 157414 [details] syslog state after unsuccessful awakening Reproduced bug this morning. PC couldn't wake up after automatic sleep.
Well this sounds rather familiar. We are having the same issue here. https://bbs.archlinux.org/viewtopic.php?id=283968 This is my current setup and is a desktop PC: OS: EndeavourOS x86_64 Kernel: 6.2.8-arch1-1 Display: Acer XZ271 (1920x1080 @ 144Hz) DE: KDE Plasma 5.27.3 WM: KWin (Wayland) CPU: AMD Ryzen 7 1700 (16) @ 4 GHz GPU: AMD Radeon RX 6700 XT (vulkan-radeon 23.0.1) It seems repeatable on X11 and Wayland. I can only think of it relating to power management, kwin or the lock screen, as KDE Plasma seems to be a repeating factor. I have had the issue for the past month having come from GNOME, which was fine. I even on the rare occasion have my CPU clock strangely where they fluctuate if I am able to get back in even though I have a fixed 4GHz manual clock. In this situation, input and audio becomes laggy until I restart the system. I had reset and updated my BIOS today on my ASUS Crosshair VI and will keep an eye out.
*My most recent comment from the Arch forums I had previously linked. Posting here to add some observed behaviour that might relate to the bug report. Happened again to me too on the LTS kernel. The system would wake with display and input seemingly not present until I unplug then plug my display back in. The background is black and it seems I can see my cursor at the very bottom edge but it doesn't move. I can get to the console and start SDDM to be met with errors, such as "Failed to write xauth file" and "Attempt 1, 2, 3... starting the Display server on vt 1 failed". I had to swap to another console instance to reboot. With one of the instances it seems the display server is running, as I am able to move the cursor but the background is black and there is nothing else I can do in the instance.
This one seems to affect only the X11- while bug #442699 affects the wayland session.
Some questions *only for the original reporter*: - Does it happen when the system locks the screen? - Does it happen when the system puts the display to sleep? - Does it happen when the system suspends? - Are there more than one screen? - Are there more than one GPU? - Is it a PRIME system with muxing? If so, which GPU was driving the display? - Is the cursor visible? - Are there any GUI elements visible? - Is the broken lock screen function (e.g. blindly typing your password and hitting Enter unlocks)? - Is there a method that brings you back to a working desktop (e.g. killing kscreenlocker_greet). - Is the desktop session using X11 or Wayland?
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!