https://bugs.kde.org/show_bug.cgi?id=523511
--- Comment #2 from [email protected] --- Comment on attachment 195383 --> https://bugs.kde.org/attachment.cgi?id=195383 Sanitized journal of one suspend/resume cycle I can reproduce this on a different system with the same error signature, though with a milder symptom: instead of a black screen, the session recovers but the whole desktop stutters/lags for ~25-30 seconds after every resume from suspend, then returns to normal on its own. === Environment === - Laptop: ASUS, AMD Ryzen iGPU (Raphael) + NVIDIA RTX 4060 Max-Q (AD107M), hybrid graphics with the internal panel wired directly to the dGPU (MUX in dGPU-direct mode; the iGPU has no attached display) - Arch Linux, kernel 7.1.8.zen1-3 - Plasma/kwin 6.7.4 (kwin 6.7.4-7) - nvidia-open-dkms 610.57.04 (driver 610.57.04), nvidia_drm.modeset=1 - Suspend mode: s2idle - VRAM suspend params (Arch defaults): PreserveVideoMemoryAllocations=1, UseKernelSuspendNotifiers=1 === What happens on every suspend/resume === At the resume instant, kwin logs exactly one failure: kwin_wayland[1478]: Applying output configuration failed! Immediately after, powerdevil's display watch (libdisplay-device, dw_watch_display_connections) wakes up and then polls every ~450-500 ms for the next ~26 seconds: org_kde_powerdevil: Watching for display connection changes, resolved watch mode = Watch_Mode_Udev, poll loop interval = 500 millisec org_kde_powerdevil: (recently_resumed_from_sleep_by_clocktime) Resume from sleep detected by BOOTTIME/MONOTONIC org_kde_powerdevil: (dw_watch_display_connections) Recently resumed from sleep detected org_kde_powerdevil: (dw_watch_display_connections) Pausing for 1000 millisec org_kde_powerdevil: (dw_watch_display_connections) Time since last return from sleep = ... ms <- repeats 56x, once per ~450-500ms org_kde_powerdevil: (dw_watch_display_connections) Time since last return from sleep = 26462 ms <- last one, 26.4s after PM: suspend exit During that window the desktop visibly stutters (compositor frame drops, input feels choppy). After it ends, everything is smooth again. The events feeding that watch are udev "change" events on i2c-dev nodes, 43 of them, all from the *AMD iGPU's* DisplayPort aux buses -- even though the iGPU drives no display on this system: org_kde_powerdevil: Udev_Event_Detail prop_subsystem: i2c-dev prop_action: change prop_devname: /dev/i2c-13 syspath: /sys/devices/pci0000:00/.../drm/card2/card2-DP-3/i2c-13/... attr_name: AMDGPU DM aux hw bus 1 These keep firing until 27s after resume. === Things that appear NOT to be involved === - The AMD iGPU itself resumes cleanly every time (SMU resume succeeds, full ring re-init, no errors): amdgpu 0000:05:00.0: SMU is resuming... amdgpu 0000:05:00.0: SMU is resumed successfully! - No NVDRM / NVIDIA GSP errors in the kernel log at any point. - CPU frequency/boost state after resume is normal (amd-pstate-epp active, boost enabled). - No failed units, no runaway processes. === Two additional observations === 1. Same as the original reporter, I have SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 set. systemd-sleep logs: "User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0). This is not recommended..." This may be a relevant common factor rather than a coincidence. 2. Fixed an unrelated local issue first (powerdevil could not read EDID via /dev/i2c-*, EACCES, user not in the i2c group). Before that fix the dw_watch polling loop never terminated (still polling 47 minutes after resume). With the permission fixed the loop now ends after ~26s, but the post-resume stutter remains -- so the i2c permission issue only made the symptom worse, it is not the root cause. Full sanitized journal of one suspend/resume cycle (with the repetitive powerdevil blocks collapsed and counted) is attached as kde-523511-resume-cycle.log. Happy to provide kwin debug output or test patches/parameters if useful. -- You are receiving this mail because: You are watching all bug changes.
