Created attachment 183385 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.

Created attachment 183386 [details]
display settings, showing layout and stuff.

Couldn't repro it on 3 screens, with one up to 144Hz. 
Does the crash happen if you only change the display rate to 144Hz (or less than 240, for that matter)?
I see said screen is in 4K, mine are only full HD, perhaps it could come from this aswell?

(In reply to MathieuM from comment #3)
> Couldn't repro it on 3 screens, with one up to 144Hz. 
> Does the crash happen if you only change the display rate to 144Hz (or less
> than 240, for that matter)?
> I see said screen is in 4K, mine are only full HD, perhaps it could come
> from this aswell?

tbh. I have not tried to fiddle with much different options. I will try to set to less than 240Hz. There are other things that can affect it also, that are already set on this 4k screen, like -- 150% scaling; HDR; variable refresh rate. Will try to toggle them off also just for the sake of it.

Setting it to 100Hz, resulted in much more severe kernel crash.
```
juuli 21 14:23:30 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:23:34 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:23:39 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:23:44 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:23:50 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:23:50 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: Failed to set workload mask 0x00000001
juuli 21 14:23:55 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:24:00 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:24:00 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: Failed to set workload mask 0x00000001
juuli 21 14:24:04 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:24:05 Zen kernel: amdgpu 0000:2f:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
juuli 21 14:24:09 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:24:14 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
```
after that I had to REISUB to not even being able to get into desktop anymore after logging in in SDDM:
```
uuli 21 14:26:14 Zen kernel: hid-generic 0003:31E3:1102.0003: offset (0) exceeds report_count (0)
juuli 21 14:26:14 Zen kernel: hid-generic 0003:31E3:1102.0003: No inputs registered, leaving
juuli 21 14:26:16 Zen bluetoothd[1130]: profiles/audio/avctp.c:avctp_server_socket() setsockopt(L2CAP_OPTIONS): Invalid argument (22)
juuli 21 14:26:24 Zen sddm-helper[1527]: gkr-pam: unable to locate daemon control file
juuli 21 14:26:44 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:26:48 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:26:48 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: Failed to set workload mask 0x00000001
juuli 21 14:26:53 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:26:58 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:27:02 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:27:07 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:27:07 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: Failed to set workload mask 0x00000001
juuli 21 14:27:11 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
juuli 21 14:27:12 Zen kernel: amdgpu 0000:2f:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
juuli 21 14:27:16 Zen kernel: amdgpu 0000:2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000005
```
because apparently kde saved the poor display settings before confirmation they were OK?? (60/60/60/100)?

Solution was to pull the cables for all satellite displays when booting, (with only 4K display attached solo) switching the main display back to 60Hz, and re-attaching all 3 other display cables.

(Btw when only the main display is connected, I can switch to whatever Hz I like and it works perfectly; problem is co-operation with multiple displays attached)

Nope. Turning scaling to 100%; HDR off and variable refresh to "Never" didn't have any effect. Still crashing. Also at the same time, when trying to set the Hz to anything other than 240Hz, causes amdgpu crash.... which I reported here:
https://gitlab.freedesktop.org/drm/amd/-/issues/?sort=updated_desc&state=opened&first_page_size=20&show=eyJpaWQiOiIzNTQ3IiwiZnVsbF9wYXRoIjoiZHJtL2FtZCIsImlkIjoxMjAyNzF9

But this kwin crash is relatively new development on top of the amdgpu thing I have had since beginning with this monitor / gpu combo.

Unfortunately the backtrace is incomplete and missing debug symbols for the following lines that we need to figure out exactly what's going wrong:

#5  0x00007f4a1ec80488 in ?? () from /usr/lib/libkwin.so.6

Could you please install debug symbols and attach a new symbolicated backtrace generated by using `coredumpctl gdb` in a terminal window? See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl for details about how to do this. Thanks again!

(In reply to TraceyC from comment #7)
> Could you please install debug symbols and attach a new symbolicated
> backtrace generated by using `coredumpctl gdb` in a terminal window? See
> https://community.kde.org/Guidelines_and_HOWTOs/Debugging/
> How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl
> for details about how to do this. Thanks again!

Can you please walk me through what exactly you want me to do?
What does it mean to "install debug symbols"? Using Manjaro linux. How do I install them? What exact packages and from where?

Apparently it's not possible, because Manjaro doesn't provide any "debug symbols packages". and for using Arch such packages, I would need to switch to unstable, which I am not going to do.

Is there a way to ... use some KDE Neon debug-distro-live-USB to do this? I mean like, If I could download "KDE debug iso", put it into USB stick, boot up from there, manage to reproduce the bug there and it itself semi-automatically reports the bugs with debugs symbols and whatnot.... wouldn't that be wonderful?

Searchable backtrace

[KCrash Handler]
#5  0x00007f4a1ec80488 in ?? () from /usr/lib/libkwin.so.6
#6  0x00007f4a1babcfa0 in drmHandleEvent (fd=18, evctx=0x7fff18616fa0) at ../libdrm-2.4.125/xf86drmMode.c:1070
#7  0x00007f4a1ec7d76d in ?? () from /usr/lib/libkwin.so.6
#8  0x00007f4a1bdd37ef in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:461
#9  doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4146
#10 0x00007f4a1bdddb40 in QMetaObject::activate<void, QSocketDescriptor, QSocketNotifier::Type, QSocketNotifier::QPrivateSignal> (sender=0x564e15eb6e20, mo=<optimized out>, local_signal_index=0, ret=0x0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs.h:306
#11 QSocketNotifier::activated (this=0x564e15eb6e20, _t1=..., _t2=<optimized out>, _t3=...) at /usr/src/debug/qt6-base/build/src/corelib/Core_autogen/include/moc_qsocketnotifier.cpp:161
#12 QSocketNotifier::event (this=0x564e15eb6e20, e=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qsocketnotifier.cpp:327
#13 0x00007f4a1d101c70 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x564e15eb6e20, e=0x7fff186172d0) at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:3303
#14 0x00007f4a1bd68118 in QCoreApplication::notifyInternal2 (receiver=0x564e15eb6e20, event=0x7fff186172d0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1106
#15 0x00007f4a1bf26629 in QCoreApplication::sendEvent (receiver=<optimized out>, event=0x7fff186172d0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1546
#16 QEventDispatcherUNIXPrivate::activateSocketNotifiers (this=this@entry=0x564e15bd79e0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp:254
#17 0x00007f4a1bf273c7 in QEventDispatcherUNIX::processEvents (this=<optimized out>, flags=..., flags@entry=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp:470
#18 0x00007f4a1cb1ad33 in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at /usr/src/debug/qt6-base/qtbase/src/gui/platform/unix/qunixeventdispatcher.cpp:27
#19 0x00007f4a1bd744b6 in QEventLoop::processEvents (this=0x7fff186174b0, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:104
#20 QEventLoop::exec (this=0x7fff186174b0, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:186
#21 0x00007f4a1bd6c7c1 in QCoreApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1449
#22 0x0000564dea96b509 in ?? ()
#23 0x00007f4a1b6376b5 in __libc_start_call_main (main=main@entry=0x564dea969340, argc=argc@entry=14, argv=argv@entry=0x7fff18617cf8) at ../sysdeps/nptl/libc_start_call_main.h:58
#24 0x00007f4a1b637769 in __libc_start_main_impl (main=0x564dea969340, argc=14, argv=0x7fff18617cf8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff18617ce8) at ../csu/libc-start.c:360
#25 0x0000564dea971b45 in ?? ()

(In reply to deemon from comment #10)
> Is there a way to ... use some KDE Neon debug-distro-live-USB to do this?

Maybe. If you installed debug packages, and were able to reproduce the crash, you could submit that crash report and link it to this one.

Searching for other reports with a similar backtrace, I did find two with very similar backtraces, it was indicated they were fixed in 6.3.0
https://bugs.kde.org/show_bug.cgi?id=496895
https://bugs.kde.org/show_bug.cgi?id=497180 -  has a Sentry report

According to Sentry, the same crashes are happening in 6.4.0 and newer, and this has regressed

https://crash-reports.kde.org/organizations/kde/issues/4603/events/138bc6805c0b46eab5de92f799817ac0/?referrer=user-feedback

This may also be related, I'm not able to merge this into it:
https://crash-reports.kde.org/organizations/kde/issues/175601/feedback/

I'll let the developers take a closer look. 
While we can't be 100% sure your crash is the same as the other two, when the others are fixed it may fix the crash on your system as well.

> Maybe. If you installed debug packages, and were able to reproduce the crash, you could submit that crash report and link it to this one.

if I were to go this route, then there are user edition; unstable edition; testing edition and developer edition. which one should I pick? also is there a version that ALREADY HAS the debug symbols installed for everything, so I don't have to install them. just boot up and reproduce bug and report it?

(In reply to deemon from comment #13)
> if I were to go this route, then there are user edition; unstable edition;
> testing edition and developer edition. which one should I pick? also is
> there a version that ALREADY HAS the debug symbols installed for everything,
> so I don't have to install them. just boot up and reproduce bug and report
> it?

I would recommend starting with the testing edition, see if you can reproduce.
If not, then try with Unstable. If you can't reproduce there, try with User.
Essentially, you'd be working from newest backward to the stable release to see where it can be reproduced (if it can).

None of the Neon editions have debug symbols installed out of the box. They are easy to install, however.
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Ubuntu-based_distros_(Ubuntu,_Kubuntu,_KDE_Neon,_Linux_Mint)

> None of the Neon editions have debug symbols installed out of the box. They
> are easy to install, however.
> https://community.kde.org/Guidelines_and_HOWTOs/Debugging/
> How_to_create_useful_crash_reports#Ubuntu-based_distros_(Ubuntu,_Kubuntu,
> _KDE_Neon,_Linux_Mint)

This requires me to actually install the Kde Neon first to actual ssd? if yes, then it's not an option. I want to keep this experiment and bugreport confined into live-USB environment, which I assume means everything should be already present on this live-USB. And wouldn't it make sense to have testing and unstable editions use those debuginfod repos by default?

(In reply to deemon from comment #15)
> This requires me to actually install the Kde Neon first to actual ssd? 

As far as I know, you can install things into the live environment. They won't persist on reboot.