https://bugs.kde.org/show_bug.cgi?id=527244
Bug ID: 527244
Summary: Since 6.8.0, explicit sync wakes the runtime-suspended
dGPU on hybrid laptops, freezing the compositor for
~2s
Classification: Plasma
Product: kwin
Version First 6.8.0
Reported In:
Platform: CachyOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
**SUMMARY**
After upgrading KWin from 6.7.5 to 6.8.0, the desktop freezes for 1–2 seconds
whenever anything on screen changes. KWin logs "The main thread was hanging
temporarily!" each time. 6.7.5 doesn't have the problem. In 6.8.0, the freezes
stop when dGPU runtime power management is disabled with `amdgpu.runpm=0`.
The laptop has two GPUs:
- iGPU: AMD Renoir (0000:07:00.0, card2 / renderD129). It drives the internal
panel.
- dGPU: AMD Navi 10 / RX 5600M (0000:03:00.0, card1 / renderD128). It has no
displays connected and is runtime-suspended (BOCO) while idle.
KWin's main thread makes a `DRM_IOCTL_SYNCOBJ_EVENTFD` ioctl on the dGPU's DRM
fd. amdgpu then runtime-resumes the dGPU inside that ioctl, which takes about 2
seconds, and KWin's main thread is blocked the whole time. A few seconds after
the wake the dGPU autosuspends again (5 s default delay), so the next frame
that needs explicit sync wakes it again.
**STEPS TO REPRODUCE**
1. Use a hybrid-GPU laptop where the dGPU has runtime PM enabled (default) and
drives no outputs.
2. Log into a Plasma 6.8.0 Wayland session.
3. Use any client that uses linux-drm-syncobj-v1 (e.g. a Vulkan/Mesa app), or
just interact with the desktop normally.
**OBSERVED RESULT**
The compositor freezes for ~2 s every time the dGPU is woken. dmesg shows a
full dGPU resume (`PSP is resuming...`, `SMU is resuming...`) for each freeze,
and the journal shows `kwin_wayland: The main thread was hanging temporarily!`.
**EXPECTED RESULT**
KWin doesn't touch the idle dGPU when compositing on the iGPU. The dGPU stays
suspended, as it did with 6.7.5.
**EVIDENCE (bpftrace)**
kprobe on `amdgpu_pmops_runtime_resume`, plus each thread's last `ioctl()` from
`sys_enter_ioctl`:
```
2026-10-16 18:34:28 WAKE comm=kwin_wayland pid=1331 tid=1331
parent=kwin_wayland_wr ppid=1325 last_ioctl fd=28 cmd=0xc01864cf
resume took 2013 ms
```
An earlier run showed the same: `comm=kwin_wayland` on the main thread, resume
took 2017 ms. `0xc01864cf` = `DRM_IOWR(0xCF, struct drm_syncobj_eventfd)` =
`DRM_IOCTL_SYNCOBJ_EVENTFD`. The other processes seen touching the dGPU in the
trace (udev workers, switcheroo-control, a `watch_displays` thread, journald)
react to the uevent that the resume itself generates. None of them triggered a
wake.
**PROBABLE CAUSE**
Commit 031d50daec ("wayland_server: make syncobj support independent of the
renderer"), first in v6.7.90.
Before this change, `LinuxDrmSyncObjV1Interface` was created with the render
backend's DRM device, which is the iGPU here.
`WaylandServer::updateSyncobjSupport()` now picks the first entry in
`GpuManager::renderDevices()` whose DRM device supports syncobj timelines:
```cpp
const auto &devices = GpuManager::self()->renderDevices();
const auto it = std::ranges::find_if(devices, [](const auto &device) {
return device->drmDevice()
&& device->drmDevice()->supportsSyncObjTimelines();
});
```
`GpuManager::scanForRenderDevices()` adds render nodes in udev enumeration
order. After the udmabuf software device, which has no drmDevice, the first one
is renderD128, the dGPU. So every client syncobj import and eventfd wait goes
through the dGPU, and amdgpu's ioctl path runtime-resumes the device on each
call. 212915b84d ("also update the drm device of linux_drm_syncobj_v1") keeps
the same selection. As of 2026-10-16 the code is unchanged on master and
Plasma/6.8.
A possible fix is to prefer the primary render device (`Compositor`'s primary
render device getter, d81d4fa2ab), or any device that isn't runtime-suspended,
and fall back to the first capable one only if there's no such device.
**WORKAROUNDS**
- `amdgpu.runpm=0` (confirmed). It costs idle battery life.
- `KWIN_RENDER_NODES=/dev/dri/renderD129:/dev/dri/renderD128` (confirmed). It
puts the iGPU first in `renderDevices()`. The dGPU then stays suspended, KWin
has no freezes, and PRIME offload (`DRI_PRIME=1`, Vulkan) still renders on the
dGPU.
**SOFTWARE/OS VERSIONS**
- Distro: CachyOS (Arch-based)
- KDE Plasma: 6.8.0 (KWin 6.8.0)
- Qt: 6.12.0
- Mesa: 26.2.4
- libdrm: 2.4.134
- Kernel: 6.18.55-2-cachyos-lts. Also seen on 7.2.9-cachyos.
- Graphics platform: Wayland
**HARDWARE**
Dell G5 5505, Ryzen 5 4600H, Radeon Renoir iGPU + Radeon RX 5600M (Navi 10)
dGPU, ATPX/BOCO runtime PM.
**ADDITIONAL INFORMATION**
Last good version: KWin 6.7.5. First bad version: 6.8.0 (upgraded 2026-10-16
09:20; the freezes started that boot).
--
You are receiving this mail because:
You are watching all bug changes.
