Stuttering after waking from sleep in KDE Wayland

I’ve had this problem for a while and couldn’t figure out when it was happening exactly but now I see it happens after every wake after a sleep. The OS pauses every few seconds for .5 seconds. Videos, mouse movement, keyboard input all stutter even with all apps closed. Restarting Wayland or relogging do nothing. Restarting fully is the only thing that works. I’ve seen other people have a similar issue with just audio. I’m wondering if it’s the same thing and they just didn’t notice the entire system pause or if my problem is different? Any ideas how to go about diagnosing it? I don’t see anything consistent in journalctl. My system is a Dell e6540 4810mq 4600hd/8790m 16gb.

Forgot to mention it doesn’t happen in X11, if it wasn’t obvious :stuck_out_tongue:

  1. Does switching to another VT and back again make a difference?

  2. Does running the following correct the behaviour?

plasmashell --replace &

The information from the following two commands might be helpful to allow others to comment further…

inxi -Ga
glxinfo -B | grep "OpenGL"

Anything consuming CPU usage excessively? (Monitor for a while)

top

Also

journalctl -xe

inxi -Ga

Graphics:
Device-1: Intel 4th Gen Core Processor Integrated Graphics vendor: Dell
driver: i915 v: kernel arch: Gen-7.5 process: Intel 22nm built: 2013 ports:
active: eDP-1 empty: DP-1, DP-2, HDMI-A-1, HDMI-A-2, HDMI-A-3, VGA-1
bus-ID: 00:02.0 chip-ID: 8086:0416 class-ID: 0300
Device-2: AMD Mars XTX [Radeon HD 8790M] vendor: Dell driver: radeon
v: kernel alternate: amdgpu arch: GCN-1 code: Southern Islands
process: TSMC 28nm built: 2011-20 pcie: gen: 3 speed: 8 GT/s lanes: 8
ports: active: none empty: VGA-2 bus-ID: 01:00.0 chip-ID: 1002:6606
class-ID: 0300 temp: 58.0 C
Device-3: Microdia Integrated Webcam driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 2-1.5:3 chip-ID: 0c45:64d0
class-ID: 0e02
Display: wayland server: X.org v: 1.21.1.12 with: Xwayland v: 24.1.0
compositor: kwin_wayland driver: X: loaded: modesetting unloaded: fbdev,vesa
alternate: intel dri: crocus,radeonsi gpu: i915,radeon display-ID: 0
Monitor-1: eDP-1 res: 1536x864 size: N/A modes: N/A
API: EGL v: 1.5 hw: drv: intel crocus drv: amd radeonsi platforms:
device: 0 drv: radeonsi device: 1 drv: crocus device: 2 drv: swrast
surfaceless: drv: radeonsi wayland: drv: crocus x11: drv: crocus
inactive: gbm
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 24.1.3 glx-v: 1.4
direct-render: yes renderer: Mesa Intel HD Graphics 4600 (HSW GT2)
device-ID: 8086:0416 memory: 1.46 GiB unified: yes display-ID: :1.0
API: Vulkan v: 1.3.283 layers: 1 device: 0 type: integrated-gpu name: Intel
HD Graphics 4600 (HSW GT2) driver: N/A device-ID: 8086:0416
surfaces: xcb,xlib,wayland

glxinfo -B | Grep “OpenGL”

OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 4600 (HSW GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.1.3
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.1.3
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.1.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Theres some strange processes that I’m not sure are spiking before sleep. kworker/2:0-i915-unordered, kworker/2:0-events and kworker/2:0-events_freezable are spiking up to 15%. I have a screenshot of my top but wasn’t able to get it with the spikes showing. Testing it before putting it to sleep shows that those kworker processes are not spiking, but I don’t know why. Still it’s a 15% spike and not 100%. Not sure what this means.


journalctl -xe doesn’t seem to show very much interesting stuff that I know how to decipher either. Here’s a screenshot of that.

But absolutely it is now stuttering after putting it to sleep and waking it up. Happens every single time. I tried making a video of it but spectacle keeps crashing after recording a video and hitting finish recording.

Sorry forgot to reply to you too, switching to another virtual console and back does nothing and neither does restarting plasmashell with --replace &. Oh and also I can’t edit my post anymore but those kworker processes are not spiking before sleep like they are after.

What is your current power management scheme? Are you using anything like TLP? If yes, disable it and try again.

All good - I was the only one replying up until now. :wink:

I think I found the solution. After looking at other people having problems with kworker I installed perf and ran a test. e1000e (ethernet) had a lot of processes running and other people had problems with that specific module in the post I read so I disabled it and so far the stutter is gone. I’m not sure if that’s something that’s fixable without disabling though. Thankfully I’m not using ethernet right now but I probably will in the future so it’d be nice to fix it. Any ideas why this module would cause problems?

This is the post I read: Kworker, what is it and why is it hogging so much CPU? - Ask Ubuntu

You could submit a bug report to help progress this. A workaround might be to unload the e1000e driver before sleep and reload it after resuming as described here (using systemd-sleep):

Where would I submit a bug? I don’t know if this is a problem with the driver or the way its being loaded resuming from sleep.

You can submit a bug here: Bugzilla

During a sleep-resume cycle the driver would usually remain loaded. However, some hardware implementations don’t cope with resuming from sleep, and needs re-initializing. So, unloading the driver before sleep, and reloading upon resume can sometimes help in these situations. Anyway, no harm in trying this approach.