You’re right, pacman -Qi kwin only lists installed from extra. I’m still learning pacman/Arch and missed the i option. Sorry.
I’ll test -12 shortly. I’m eating right now.
-12 took a lot longer to hang. I don’t know if it’s helpful, but here’s the end of my journalctl.
Summary
❯ journalctl -b -1 | tail
Feb 17 17:04:27 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
Feb 17 17:04:27 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
Feb 17 17:04:28 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
Feb 17 17:04:28 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
Feb 17 17:04:28 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
Feb 17 17:04:28 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
Feb 17 17:04:28 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
Feb 17 17:05:43 castle NetworkManager[807]: [1739833543.9984] device (wlan0): set-hw-addr: set MAC address to 0A:4D:96:B1:E9:DB (scanning)
Feb 17 17:06:18 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
Feb 17 17:06:18 castle kwin_wayland[1064]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated.
I have the same behavior at both of my CachOS Laptops. At both i can relative easy reproduce the freezing: Take a window at the title bar (no matter where it’s placed at the screen) and push it to the upper screen border.
If i do so, the system freezes reliable. If don’t do it the system works for days.
It looks to me like the calculation of the window placement didn’t accept a negativ value ( i suggest the upper border is 0 )
One more thing i noticed which could have the same base:
I’m using several virtual desktops. Since the “freezing prob.” ocures i can also not move a window from one virtual desktop to an other.
Edit: Both Systems are AMD Ryzen with integreated graphics only. A old Ryzen 5700U and a new Rayzen 8845HS
I’m glad to hear it’s not just me having the problem.
I’ve also had it freeze dragging to the bottom of the screen a few times.
My system is a Ryzen 7 3700X with an Nvidia RTX 2070 Super.
My desktop is running Wayland on Nvidia Open driver 570 at 144 Hz scaled to 150%.
I have a second virtual desktop that I only use once a week. I wonder if that’s related.
I like the virtual desktop system… I use Linux since 25 Jears now and it is one of the big advantages to me. Usualy i have several App’s open and placed at different v.-dektops, Changing between in my mind is more comfortable because i don’t need to search for it at the controll pannel: I know Email is at desktop one 
Yes i Think so, both actions are Window movements and i think both managed with kwin
But back to theme: Did you try to reproduce the freeze by pushing a window to the top of the screen?
Dragging windows to the top of the screen is how I first noticed it. The bottom came later.
Unfortunately, the logs aren’t very verbose. I give up on this. The last build already has no optimizations enabled, except LTO (may be the issue). The issue being reproducible on Arch’s package suggests that this is indeed an upstream issue. 6.3.1 is supposedly releasing today so can you please wait until then and see if you can reproduce?
I just posted the last few lines of the log. I can send you more if you want. But it’s probably best to wait and test 6.3.1 first, since it should be out soon.
thanks! I am new to CachyOS and it solved my issues with freezing so far!
Unfortunately, it still freezes, but less often 
I hope this will be fixed in future updates. I really like the distro, but I came from Zorin, which was rock-solid stable. I’ll wait a week and see how things go.
I upgraded to 6.3.1-2 and got a hang dragging to the bottom. I’ll install the 6.3.1-1 Arch package from extra and try it out, unless you want info/logs from the -2 currently installed first?
It will likely be the same 
Let me find the env var that would make Kwin logs more verbose first. I will follow up soon, thanks!
Yup I have this issue as well.
It happens A LOT sooner if you have an app using or displaying graphics in a window.
GOverlay with its second window that renders the box, if you drag this to the top of the screen as the OSD is loading it will INSANTLY lock up the system.
Also OBS as its grabbing your screen to display in its preview window will also INSANTLY lock up the screen when dragged to the top of the screen to maximise.
here is a bugreport not sure if its useful as I have to force reset with button on case when the system locks up so this was done after first reboot.
Is there anyway to step down to latest stable KDE 6.2?
edit:
moved to gnome for the time being until this is fixed. zero issues on gnome just some slight flicker using certain desktop apps using the VRR experimental feature.
I had to do this as well, as mine was also freezing lol. Good to know it’s not my hardware.
I sounds like the issue I got. I have it now in CachyOS and I had it before in EOS.
Its either the Kernel or KDE. I don’t know which and Journalctl gives no good info. System just randomly turns to a crawl, go down to single digits like its 1-2 FPS.
I press Win key + type reboot, to get it out of this mess.
I’m willing to help debug as much as possible but I think the issue is KDE. But I really think I had the same problem with the 6.13-6.14 kernel on EOS and later KDE came around, but I can’t say for sure. Since more and more say KDE 6.3, maybe it was KDE all this time.
EDIT: I can add I cannot replicate it. Its always random.
EDIT2: Found your awesome script for bug reports.
Workaround hard freeze during interactive move (!7225) · Merge requests · Plasma / KWin · GitLab (hack) or window: reimplement restriction in moveResize (!5296) · Merge requests · Plasma / KWin · GitLab (proper fix) should hopefully fix this.
Edit: The former should be releasing today for 6.3.2