Bug 517987

Same problem on cachy-os with kde 
Display (GSM5C56): 1920x1080 in 27", 60 H*
Display (BOE0823): 1920x1080 in 17", 60 H]
Display (LG HDR 4K): 1920x1080 in 27", 60]
DE: KDE Plasma 6.6.3
WM: KWin (Wayland)
CPU: AMD Ryzen 9 5900HX (16) @ 4.68 GHz
GPU 1: NVIDIA GeForce RTX 3070 Mobile / M]
GPU 2: AMD Radeon Vega Series / Radeon Ve]
Memory: 11.23 GiB / 30.70 GiB (37%)
Swap: 0 B / 30.70 GiB (0%)
Disk (/): 258.31 GiB / 1.82 TiB (14%) - bs

Big problem is that journalctl writes about 20-40 mB/s of logs on disk.
Affected version of kwin for me
kwin 6.6.3-1.1
nvidia drivers:
linux-cachyos-nvidia-open 6.19.6-1 (drivers 595.45.04)

The problem remains on drivers 595.58.03

btw. in my first report the platform is shown to be X11, while it is Wayland. It was an automatic copy from system settings... interesting.

Please get the output of wayland-info on an older driver without the issue and on the new one.

Created attachment 191013 [details]
wayland info output on a driver with the problem

(In reply to Zamundaaa from comment #3)
> Please get the output of wayland-info on an older driver without the issue
> and on the new one.

I can't show from the older driver version. I have nvidia drivers installed from the nvidia repository and it seems they don't keep the older versions. Otherwise I would downgrade to avoid this nightmare.

Any other info I can provide? Reverting to the old driver causes the whole KDE to hang after login, so wayland-info can't be provided.

(In reply to Lech from comment #6)
> Any other info I can provide? Reverting to the old driver causes the whole
> KDE to hang after login, so wayland-info can't be provided.

It seems, at least for my distro (cachyos) that downgrading gpu drivers strictly implies also having to deal with kernel problems, it's probably the same for you, maybe you didn't downgrade correctly or just can't, I might suggest using ctrl+alt+f1 to get the wayland-info command done before loggin-in.
Also to cite some recent external references:
https://forums.developer.nvidia.com/t/bug-invalid-framebuffer-status-gl-framebuffer-incomplete-missing-attachment/363108 seems like it's due because of nvidia drivers, moreover the workaround that I did myself and seems to partially work is https://bbs.archlinux.org/viewtopic.php?pid=2290146#p2290146 
Also on cachyos forums:
https://discuss.cachyos.org/t/ssd-is-at-max-writing-all-the-time/26409/20
"I found an interesting thread on the KDE bug-tracker site about this error from a few months ago. Pay attention to comments #7 and #10, where it is suggested that at least for that person, an external monitor connected to a dual-GPU laptop is the cause, and the logging level can be set lower to surpress these messages.
bugs.kde.org
511852 – Journal entries like: GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
people also present a command to revert the drivers on cachy os
I hope to have helped a bit aggregating some more details

Created attachment 191197 [details]
kwin-wayland-bug-report

Same problem, created an attachment https://bugs.kde.org/attachment.cgi?id=191197 with my logs

Created attachment 191199 [details]
595-driver-with-fix

Created attachment 191200 [details]
595-driver-without-fix

Created attachment 191201 [details]
580-driver-without-fix

Hopefully I downgraded correctly.
I uploaded also the wayland-info with the fix stated here https://bbs.archlinux.org/viewtopic.php?pid=2290146#p2290146
After downgrading the drivers to 580, I still receive the error with an added line "Failed to create framebuffer: Invalid argument" but only about every minute (I don't get 20mb/s logs on the ssd anymore) while the error occurs, the screen freezes for about 1-2 seconds then everything resumes normally, so the problem was present before already in 580.
From the research on the internet it seems that the problem is caused by bad nvidia drivers, at first I thought it was a problem with new version of kde. Maybe there's a way to workaround whatever is being used in the drivers that causes the issue.
Thanks

So I spent some time staring at the drm backend code, and can't really explain this. KWin decides on format+modifiers once, and then the same buffers get re-used afterwards (and when additional ones are allocated, the same format that worked before is used).
I also can't replicate this on my setup. Maybe it's specific to AMD->Nvidia, and doesn't happen with Intel?

FWIW for Plasma 6.7 I rewrote a lot of the multi GPU copy code. By default it uses Vulkan now, so there's a decent chance the issue will go away with that.

*** Bug 519597 has been marked as a duplicate of this bug. ***

Alright, I managed to trigger it now. The cause is that the Nvidia driver doesn't support rendering to linear buffers with OpenGL, but it does support allocating linear buffers.
Our multi GPU copy path doesn't do an early check for whether or not rendering to the allocated buffer is supported, so it re-tries every frame for the cursor, and when rendering fails, it falls back to a software cursor instead. The OpenGL errors thus get logged every single frame the cursor is visible.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9158

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9159

*** Bug 518206 has been marked as a duplicate of this bug. ***

Git commit 4729b0bb8b51af77181df7aae6ce2ae81a128784 by Xaver Hugl.
Committed on 30/04/2026 at 13:50.
Pushed by zamundaaa into branch 'master'.

backends/drm: drop dmabuf import modes

Their usefulness is questionable, and on some drivers they happen to prevent
the fallback to CPU copy for the cursor from working, since addFB succeeds
somehow, but the atomic test later fails.
If we later find some hardware where it's proven to be beneficial, we can add
this path back with checks specific to that hardware.

M  +2    -19   src/backends/drm/drm_egl_layer_surface.cpp
M  +0    -2    src/backends/drm/drm_egl_layer_surface.h

https://invent.kde.org/plasma/kwin/-/commit/4729b0bb8b51af77181df7aae6ce2ae81a128784

Git commit 413face71a9b4c622c2817b8da5d888e2cd77f38 by Xaver Hugl.
Committed on 30/04/2026 at 13:55.
Pushed by zamundaaa into branch 'Plasma/6.6'.

backends/drm: don't attempt multi GPU copies with unsupported formats

Specifically with the proprietary Nvidia driver, the plane requires a linear
modifier, which we can't render to with OpenGL. When attempting to render with
that buffer, we end up logging errors at a really high rate, and falling back
to a software cursor rather than another import mode.

M  +6    -1    src/backends/drm/drm_egl_layer_surface.cpp

https://invent.kde.org/plasma/kwin/-/commit/413face71a9b4c622c2817b8da5d888e2cd77f38

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9162

Git commit 64d608907fc427b0791d7531959010c5093eb69e by Xaver Hugl.
Committed on 30/04/2026 at 15:26.
Pushed by zamundaaa into branch 'Plasma/6.6'.

backends/drm: drop dmabuf import modes

Their usefulness is questionable, and on some drivers they happen to prevent
the fallback to CPU copy for the cursor from working, since addFB succeeds
somehow, but the atomic test later fails.
If we later find some hardware where it's proven to be beneficial, we can add
this path back with checks specific to that hardware.
(cherry picked from commit 4729b0bb8b51af77181df7aae6ce2ae81a128784)

M  +3    -19   src/backends/drm/drm_egl_layer_surface.cpp
M  +0    -2    src/backends/drm/drm_egl_layer_surface.h

https://invent.kde.org/plasma/kwin/-/commit/64d608907fc427b0791d7531959010c5093eb69e

With these commits, the next bugfix release should take care of this. Until then, you can use
> KWIN_FORCE_SW_CURSOR=1
to work around the issue.

Thanks for the support! can't wait for the release :)

*** Bug 519426 has been marked as a duplicate of this bug. ***

*** Bug 519856 has been marked as a duplicate of this bug. ***

*** Bug 519997 has been marked as a duplicate of this bug. ***

Even after 6.6.5 update, it feels like this not been fixed, while no errors in log, there are still "lesser" version of stutter with same time intervals as before.
When before stutters felt like drop to 10 fps from 60 (for overall system), now it feels like drop to 40 from 60. Which is improvement, yet something bad still happens.

Not sure how i can help or what info i need to provide, but will be glad to cooperate with that issue.

Please don't reopen bug reports for related but not the same issues.

In this case, multi-gpu copies with the proprietary Nvidia driver are known to be very slow. There's nothing we can do about it except wait for Nvidia to fix it.
If that's a regression compared to a past version of KWin, please do open a new bug report about it though.