| Summary: | Screen not restored after awakening from hibernate | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | sk.griffinix |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 5.27.7 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
journalctl log
dmsg log with bug NOT Reproduced dmesg log with bug reproduced |
||
|
Description
sk.griffinix
2023-08-24 20:17:15 UTC
Please enable drm debug logging with > echo 0x1FF | sudo tee /sys/module/drm/parameters/debug start writing the log with > sudo dmesg -w > dmesg.log then reproduce the problem and stop the last command. The resulting log file might contain information telling us what's happening. Note that the logging is *very+ verbose, so if reproducing the problem doesn't work the first time, it's best to stop the dmesg command and start it again before trying again, so that it's easier to find the relevant parts of the log. (In reply to Zamundaaa from comment #1) > Please enable drm debug logging with > > echo 0x1FF | sudo tee /sys/module/drm/parameters/debug > start writing the log with > > sudo dmesg -w > dmesg.log > then reproduce the problem and stop the last command. The resulting log file > might contain information telling us what's happening. > > Note that the logging is *very+ verbose, so if reproducing the problem > doesn't work the first time, it's best to stop the dmesg command and start > it again before trying again, so that it's easier to find the relevant parts > of the log. So if I am understanding correctly, hibernate after running the above command is creating log and upload the log file in case I get the bug. Ok, I will get on with it. Just a doubt though. On running `modinfo -p drm`, I get a bunch of codes but 0x1FF is not one of them. What does this code do? Yes, that is correct.
> On running `modinfo -p drm`, I get a bunch of codes but 0x1FF is not one of them. What does this code do?
0x1FF is just the combination of all the flags, with all bits set. The goal is to get all drm-related logging from the kernel, so that we don't miss anything that might be relevant
Created attachment 161180 [details]
dmsg log with bug NOT Reproduced
I tried a couple of times but couldn't reproduce the bug. I am attaching dmsg log just in case its needed for comparing with log where bug is reproduced. Its really very verbose.
Created attachment 161308 [details]
dmesg log with bug reproduced
Had this bug today after hibernating today
Should I provide any further info? Had this issue again and lost data again. This is making it very difficult for me to use kde for any serious endeavour. If nothing, is there some way to remove flickering horizontal lines by restarting kwin or resetting graphics srivers or any other method that does not remove all running programs? Sorry, it's been a busy week and I haven't been able to go through all my emails yet. The most suspicious things in your log are > [35707.959388] [drm] Fence fallback timer expired on ring sdma0 a bunch of times (which also happens once in your first log, so not necessarily related) and > [35707.977814] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* channel eq failed: 5 tries > [35707.978425] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* channel eq failed which does sound related. Link training is about creating a working connection with your monitor, so if that doesn't work properly it could definitely cause issues like you describe. Please put `KWIN_DRM_NO_AMS=1` into /etc/environment, reboot and then check if your workaround starts working again with that (In reply to Zamundaaa from comment #7) > Please put `KWIN_DRM_NO_AMS=1` into /etc/environment, reboot and then check if your workaround starts working again with that the workaround to switch tty to restore screen didn't work after adding the above variable Okay, then I'm pretty certain that it's not caused by something that KWin does wrong. Please report the bug at https://gitlab.freedesktop.org/drm/amd/-/issues, hopefully they can help fix the underlying kernel problem. It should be helpful for them if you attach the dmesg log from here as well Submitted to https://gitlab.freedesktop.org/drm/amd/-/issues/2845 |