Created attachment 153635 [details] Journalctl logs when resuming from sleep SUMMARY When i resume my PC from sleep, it unfortunately often doesn't work correctly. In particular, one display (my primary 4k screen, connected via DP) stays completely black and doesn't seem to have a connection. The other display (secondary FHD screen, connected via HDMI) is even weirder: It is always active, so it has some kind of connection to the PC, but either shows just a black screen or, and this is even worse, the last active state before the system was put into sleep. So mostly Spotify, which is what i am normally running on my secondary screen, but it could also be my last emails, which is quite a security risk (no lock screen or whatsoever shown). The system is not responsive, and the only solution is to reboot it, which is really annoying when you have open projects. I am having this problem since at least a few months now, so I finally decided to open a bug report. STEPS TO REPRODUCE I did not find a way to consistently reproduce this, but it happens at least every third time I resume the system from sleep. 1. Put the system into sleep 2. Resume it 3. OBSERVED RESULT Already described it above. EXPECTED RESULT It should turn on both of the displays and show the lock screen. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 5.15.76-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 6 × Intel® Core™ i5-8600K CPU @ 3.60GHz Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6800 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7B46 System Version: 1.0 ADDITIONAL INFORMATION I attached a log from journalctl. If you have better ideas where to find logs, please tell me.
If just discovered that i already submitted a bug report for this problem. But as it's (according to Nate) in the wrong category (not kwin or plasmashell) and hasn't received any feedback until now, i will close it in favour of this issue. https://bugs.kde.org/show_bug.cgi?id=459596
*** Bug 459596 has been marked as a duplicate of this bug. ***
Can you attach the output of `kscreen-doctor -o` before the problem happens, and then again after it happens (i.e. after waking up from sleep/hibernate and the one of the screens didn't come back).
(In reply to Nate Graham from comment #3) > Can you attach the output of `kscreen-doctor -o` before the problem happens, > and then again after it happens (i.e. after waking up from sleep/hibernate > and the one of the screens didn't come back). Here is the output before the problem happened: ``` Output: 1 Philips Consumer Electronics Company PHL 326M6V/354 enabled connected primary DisplayPort Modes: 0:3840x2160@60*! 1:3840x2160@60 2:3840x2160@60 3:3840x2160@50 4:3840x2160@30 5:1920x2160@60 6:2560x1440@60 7:1920x1200@60 8:1920x1080@60 9:1920x1080@60 10:1920x1080@60 11:1920x1080@50 12:1600x1200@60 13:1680x1050@60 14:1280x1024@75 15:1280x1024@60 16:1440x900@60 17:1280x960@60 18:1280x800@60 19:1280x720@60 20:1280x720@60 21:1280x720@60 22:1280x720@50 23:1024x768@75 24:1024x768@70 25:1024x768@60 26:832x624@75 27:800x600@75 28:800x600@72 29:800x600@60 30:800x600@56 31:720x576@50 32:720x576@50 33:720x480@60 34:720x480@60 35:720x480@60 36:720x480@60 37:640x480@75 38:640x480@73 39:640x480@67 40:640x480@60 41:640x480@60 42:640x480@60 43:720x400@70 44:2560x1600@60 45:3200x1800@60 46:2880x1620@60 47:1600x900@60 48:1368x768@60 Geometry: 0,0 3072x1728 Scale: 1.25 Rotation: 1 Overscan: 0 Vrr: Automatic RgbRange: unknown primary Output: 2 Acer Technologies Acer S222HQL/LR0080194201 enabled connected HDMI Modes: 0:1920x1080@60*! 1:1920x1080@60 2:1920x1080@60 3:1920x1080@60 4:1920x1080@60 5:1920x1080@50 6:1920x1080@50 7:1280x1024@75 8:1280x1024@60 9:1280x960@60 10:1280x800@60 11:1152x864@75 12:1280x720@60 13:1280x720@60 14:1280x720@60 15:1280x720@50 16:1280x720@50 17:1024x768@75 18:1024x768@70 19:1024x768@60 20:832x624@75 21:800x600@75 22:800x600@72 23:800x600@60 24:800x600@56 25:720x576@50 26:720x576@50 27:720x480@60 28:720x480@60 29:720x480@60 30:720x480@60 31:640x480@75 32:640x480@73 33:640x480@67 34:640x480@60 35:640x480@60 36:640x480@60 37:720x400@70 38:1600x900@60 39:1368x768@60 Geometry: 3072,739 1920x1080 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic ``` Unfortunately, I can't give you the output directly after the problem occurred, as the whole system is unresponsive then. As I've already written, the only way to use the system again is a hard reset.
Ok, then that sounds like a KWin issue, not a KScreen issue. Moving the ticket there.
Can you attach the output of: - drm_info (you may need to get the package for it from AUR) - qdbus org.kde.KWin /KWin supportInformation Also please add > QT_LOGGING_RULES="kwin_*.debug=true" to your /etc/environment file, reboot, reproduce the problem again, reboot, and upload the output of > journalctl --boot 1 | grep kwin_wayland_drm Thanks!
Can you still ssh into the system once the graphical bits are frozen?
(In reply to Zamundaaa from comment #7) > Can you still ssh into the system once the graphical bits are frozen? I've never tried this out, but I will set up a SSH server and try to connect the next time it happens.
Created attachment 153693 [details] DRM Info output
Created attachment 153694 [details] Kwin Support Info Output
Created attachment 153695 [details] Journalctl logs no real sleep and no wakeup possible Something is definitely broken with my suspend functionality. The first time I put my system into sleep was all fine. The system was suspended, my chassis LED showed that it's now in sleep, and when I pressed a key it woke up without any problems. So I decided to do this one more time directly afterwards, but this time nothing worked. The displays went black, but apart from that the computer didn't seem to turn off/ go into sleep state. The chassis LED was still in "normal operation mode" (or whatever you would call it). This didn't change in the next minutes, so I tried to wake the system up again, but it was not possible. Not by pressing any key or by pressing the power button of my PC. SSH was also unreachable btw. The only way to get it back running was a hard reset. I know this is not the issue that I reported, but FYI I still upload the journalctl logs, maybe you are able to find something interesting. I will watch out for the original issue to happen again.
(In reply to Nate Graham from comment #3) > Can you attach the output of `kscreen-doctor -o` before the problem happens, > and then again after it happens (i.e. after waking up from sleep/hibernate > and the one of the screens didn't come back). Here you go, it has just happened again and I am indeed able to connect via SSH to my machine. However the kscreen-doctor output doesn't help: kscreen-doctor -o >qt.qpa.xcb: could not connect to display >qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. >This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. >Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb. Also drm_info is just infinitely loading and produces no output at all. Same for "qdbus org.kde.KWin /KWin supportInformation", but if i start it with sudo rights, it return the following: >Could not connect to D-Bus server: org.freedesktop.DBus.Error.NotSupported: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead As i am not sure which other commands could produce any useful debugging outputs, I will just attach the lshw output.
Created attachment 153737 [details] LSHW after resume when problem happend
I am not sure, but looking at the logs i would say that it's some sort of AMD driver issue. I now upgraded my kernel from 5.15 to 5.19 and hope that this will improve the situation.
> drm_info is just infinitely loading and produces no output at all Yeah that does sound like a driver issue. If you can ssh in again when the problem happens, the output of dmesg could help figure out what's going on. You can save it like so: sudo dmesg > ~/dmesg.log
After I upgraded from kernel 5.15.78 to 5.19.17 I did not experience this problem any more. The problems while putting the system into sleep mode are also gone. You can close this issue if you want to.