Bug 471136

From the description, it does sound like kwin_x11 is what's freezing here, not xorg. While frozen, switch to a real tty and run the following:

sudo gdb  --pid `pidof kwin_x11` 

wait for that to load and type:
set logging on
set pagination off
bt
quit

This will save a file called gdb.txt in your home directory with the backtrace.

(In reply to Nate Graham from comment #1)
> From the description, it does sound like kwin_x11 is what's freezing here,
> not xorg. While frozen, switch to a real tty and run the following:
> 
> sudo gdb  --pid `pidof kwin_x11` 
> 
> wait for that to load and type:
> set logging on
> set pagination off
> bt
> quit
> 
> This will save a file called gdb.txt in your home directory with the
> backtrace.

Thanks. The problem is that if I kill it, or toggle it, it never crashes then. lol

(In reply to Jason Straight from comment #2)
> (In reply to Nate Graham from comment #1)
> > From the description, it does sound like kwin_x11 is what's freezing here,
> > not xorg. While frozen, switch to a real tty and run the following:
> > 
> > sudo gdb  --pid `pidof kwin_x11` 
> > 
> > wait for that to load and type:
> > set logging on
> > set pagination off
> > bt
> > quit
> > 
> > This will save a file called gdb.txt in your home directory with the
> > backtrace.
> 
> Thanks. The problem is that if I kill it, or toggle it, it never crashes
> then. lol

Freezes, I mean.

Dur. I had a stupid moment, apparently. I was thinking your instructions included a kill and restarting with gdb. lol. I'll try this weekend. Thanks again.

Created attachment 160034 [details]
kwin_x11 gdb backtrace

Comment on attachment 160034 [details]
kwin_x11 gdb backtrace

This was taken as per instructed, after kwin_x11 was frozen.

I noticed something else about my "fix" for this, where I have a script run to dbus toggle compositing off/on. During the last couple weeks, I have never had a freeze using this method, but there's another bug that disappeared for me as well.

Most times I would shut down or reboot my machine, it wouldn't finish shutting down. It would get stuck on a "shutting down" type message on the TTY. I was able to toggle to TTY7 and back and it would continue shutting down.

But, since I've been toggling compositing on every login, I have not had that issue.

I know there's another bug (saw mentioned on reddit) where SDDM is supposedly addressing that bug, but it could be related, or maybe some people are suffering that issue for another reason.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

I was experiencing this or a similar bug on an AMD iGPU. The screen would freeze but the mouse could be moved around. Music continued to play. After a few seconds it un-freezes.

I was toying around with Disabling Desktop Effects:
* Morphing Popups
* Sliding Popups
* Squash (minimize effect)

And after clicking apply, the bug went away. I re-enabled those effects but I could no longer reproduce.

------

I could previously easily reproduce the bug by:
* Spamming Meta key to open the app launcher (froze opening and closing).
* Gliding over the panel tasks in the taskmanager widget.
* Alt+Tabing.
* Opening/Closing Yakuake

Previously I killed kwin_x11 and the bug went away when opening/closing the app menu with the mouse.

I tried disabling the compositor with the toggle key Alt+Shift+F12. I did not disabled it from startup in System Settings > Compositor > Enable on Startup. I still experienced the bug after disabling the compositor with the toggle key, but maybe I did not actually disable it? I need to confirm this in a fresh KDE install.

I previously installed Ubuntu (Gnome3 based) in another partition and did not experience this bug so it's not the Kernel.

-----

Operating System: openSUSE Tumbleweed 20230801
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.6-1-default (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics ( https://www.amd.com/en/product/11176 )
Memory: 13.5 GiB of RAM (Corsair Vengence LPX 3600Ghz 2x8 GB sticks, with 2GB? dedicated to VRAM)
Graphics Processor: AMD Radeon Graphics
Manufacturer: Micro-Star International Co., Ltd. (MSI Pro B550M-VC WIFI)
Product Name: MS-7C95
System Version: 3.0

-----

- [YES] Entire desktop image is frozen
- [YES] Pointer still works
- [YES] Pointer still operates on desktop under frozen image (more on that below)
- [TODO] killall -9 kwin_x11 and relaunching kwin_x11 recovers
  - If during the freeze, I tried to operate on any windows with pointer, they now show up in updated positions/sizes, etc.
- [TODO] Does not happen if compositing is disabled
- [DID NOT CHECK] Does not happen on kernels older than 6.1.9
- [?] Does not happen with any other program
- [YES? TODO Was it Xorg or Wayland?] Does not happen on Gnome+Xorg
- [TODO] Does not happen on Plasma+Wayland (But too many other things don't work for me)
- [TODO] Does not happen if compositing is toggled off then on after logging in
- [NO, kwin_x11 --replace still has the bug] Does not happen a 2nd time if kwin is killed and restarted
- [TODO] Happens with a new user and user profile with default settings

I'm no longer on Tumbleweed (for now). Using Endeavour. Just today I decided to see if I still have the problem by disabling my startup script that runs `kwin_x11 --replace` on login. A little while later, kwin froze.

Just thought it was worth mentioning that it still exists and it's not isolated to a single distro.

Operating System: EndeavourOS 
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11
Kernel Version: 6.6.1-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 20 × 12th Gen Intel® Core™ i9-12900H
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ROG Strix G733ZW_G733ZW
System Version: 1.0

With plasma6, this is now also present in Wayland, but the behavior changed a little, and my fix no longer works.

Now, it'll freeze for several seconds and recover, every few minutes. It seems watching videos in the browser makes it happen more often. Most of the time, I'm lucky to get 5-10 minutes.

On Xorg, It's still dependent on compositing being enabled. If disabled, it doesn't happen.

I've tried turning off every effect, to no avail.

I've tried every environment variable option for kwin.

Still only happens with intel driver. Switching to nvidia driver doesn't have issue.

Tried w/o a task bar, in case it was something to do with thumbnails.

No problems on kwinft, compiz, Gnome. Definitely a kwin only issue. Compiled kwinft for dev branch last night and it's been going without a freeze, or at least for a lot longer than I could have gone on kwin without one.

(In reply to Jason Straight from comment #5)
> Created attachment 160034 [details]
> kwin_x11 gdb backtrace

The freeze is in Qt code, not sure what could cause it.

> Now, it'll freeze for several seconds and recover, every few minutes

It sounds like https://gitlab.freedesktop.org/drm/intel/-/issues/9571

I can't say what changed from last night to today with certainty, but the wayland session is no longer having this issue.

kernel, qt, libgl, or kde updates? But I'm happy about that. I guess I'll have to try an X session to see.

Operating System: openSUSE Tumbleweed 20240130
KDE Plasma Version: 6.0.80
KDE Frameworks Version: 5.249.0
Qt Version: 6.6.1
Kernel Version: 6.7.2-1-default (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i9-12900H
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ROG Strix G733ZW_G733ZW
System Version: 1.0

If wayland session still freezes, check if KWIN_FORCE_SW_CURSOR environment variable is set. Also it would massively help if you could get kwin_wayland's backtrace when the screen is frozen.

Xorg still freezes, but at least I can say that wayland does not, including on RC2.

Does it still freeze with the same backtrace?

Created attachment 165767 [details]
kwin_x11 gdb.txt 5.93.0-1

I'm no dev, so I can't really say if it's the same issue from looking at the trace, but this is with X and on arch this time. The last trace on X was with opensuse TW.

I found a workaround for the momentary freezes of desktop contents. It's not ideal, but it's more ideal than disabling compositing on kwin_x11.

I really wish I could use wayland, but I just can't not have working autotype in my password manager for the amount of remote work I do, where copy/paste isn't an option.

The workaround I found was to disable glamor (acceleration) in the modesetting x11 driver with `Option "AccelMethod" "none"`.

*** This bug has been marked as a duplicate of bug 481721 ***

I don't think this is the same as the bug it was marked as a duplicate of, which was marked as resolved in Feb. I'm still having the same freeze. In fact I just had it while I was writing this.

Unless the changes still have not made it into release?

I'm currently on:

Operating System: openSUSE Tumbleweed 20240517
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.8.9-1-default (64-bit)
Graphics Platform: X11
Processors: 20 × 12th Gen Intel® Core™ i9-12900H
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ROG Strix G733ZW_G733ZW
System Version: 1.0

I see now. The original problem remains.

For a while, there was an additional issue where it would hang and (possibly) unhang itself after a bit.

The original problem where the desktop contents all freeze and it doesn't recover is still an issue.

> The original problem where the desktop contents all freeze and it doesn't
> recover is still an issue.
Can confirm this issue exists have been encountering it for a while
Jul 22 01:22:52 TheDevil kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:e75ffefe, in kwin_wayland [1839]
Jul 22 01:22:52 TheDevil kernel: i915 0000:00:02.0: [drm] kwin_wayland[1839] context reset due to GPU hang

I know this wouldn't be a proper "fix", but could we either have, or is there, a way to watchdog monitor or communicate (ping) kwin_x11 and if no response is received, it can be restarted by a kwin_watchdog kind of script or process?

I'm not sure it's even possible with this particular bug, but it's the compositor. Maybe some way to see if the compositor is frozen?