https://bugs.kde.org/show_bug.cgi?id=527244
--- Comment #4 from [email protected] --- The rpm_resume tracepoint, filtered to 0000:01:00.0, shows kwin_wayland as the only process resuming the dGPU: kwin_wayland-783 [004] d..1. 364.489325: rpm_resume: 0000:01:00.0 flags-4 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 Setting /sys/bus/pci/devices/0000:01:00.0/power/control to "on" stops both the wakes and the hangs (0 in 2.5 min), which matches the amdgpu.runpm=0 workaround. Why the dGPU gets picked here: Udev::listRenderNodes() returns the render nodes in libudev enumeration order without sorting (unlike Udev::listGPUs(), which sorts boot_vga first). On this machine udevadm info -e lists them in syspath order, and the dGPU's PCI path sorts before the iGPU's: /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD129 /devices/pci0000:00/0000:00:02.0/drm/renderD128 So updateSyncobjSupport() (since 031d50daec, first renderDevices() entry that supports syncobj timelines) picks the suspended dGPU instead of the iGPU that actually composites. Before that commit, setRenderBackend() used backend->renderDevice(). Any machine whose dGPU root port enumerates before the iGPU should hit the same thing. Workaround confirmed: KWIN_RENDER_NODES=/dev/dri/renderD128:/dev/dri/renderD129 (via ~/.config/environment.d, then re-login) gave 0 hangs over about 4 minutes; after a few dGPU wakes from apps starting at login, no further wakes for 13+ minutes. Preferring the compositing device, or at least a device that is not runtime-suspended, in updateSyncobjSupport() as the reporter suggested would avoid this. -- You are receiving this mail because: You are watching all bug changes.
