Bug 483600

Summary:	KDE Plasma freezes entire system when enabling second monitor
Product:	[Plasma] kwin	Reporter:	pigladal
Component:	multi-screen	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED WAITINGFORINFO
Severity:	grave	CC:	xaver.hugl
Priority:	NOR	Keywords:	qt6
Version:	6.0.2
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Output of "journalctl --boot -1"

Description pigladal 2024-03-14 19:42:08 UTC

SUMMARY
When starting KDE Plasma 6, my second monitor is not enabled by default. Going to the settings menu and trying to turn on my monitor causes the entire system to freeze to the point that I cannot even use the Ctrl+Alt+F2 command to bring up a shell to kill Plasma and restart it. This only started happening after upgrading to Plasma 6.0.2 from the Arch repos.

STEPS TO REPRODUCE
1.  Go to System Settings, then Display Configuration
2. Click on Dell Inc. DELL M991 on menu, then click the checkmark to enable it
3. Click "Apply"

OBSERVED RESULT
System becomes entirely unresponsive, any sound that was playing loops over and over, I can hear the second monitor turning on but nothing displays on it. I have no choice but to hard reset the system when it happens.

EXPECTED RESULT
The second monitor comes on and I can move applications over to it.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.9-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 6800 XT
Product Name: X570 Steel Legend WiFi ax

ADDITIONAL INFORMATION
The second monitor actually works and displays the login screen when logging on on SDDM, however the monitor gets disabled when logging into Plasma.

Comment 1 Zamundaaa 2024-03-14 20:47:10 UTC

Please check your journal from when the hang happened
> journalctl --boot -1
If audio is looping for you, it'll most likely contain a backtrace for some kernel crash

Comment 2 pigladal 2024-03-14 22:00:16 UTC

Created attachment 167207 [details]
Output of "journalctl --boot -1"

Comment 3 pigladal 2024-03-14 22:00:34 UTC

I've attached the output of the command piped into a text file.

Comment 4 Zamundaaa 2024-03-14 22:52:34 UTC

Was that on the boot after you triggered the hang? Other than some benign warnings, there's nothing suspicious in the log

Comment 5 pigladal 2024-03-14 23:24:09 UTC

(In reply to Zamundaaa from comment #4)
> Was that on the boot after you triggered the hang? Other than some benign
> warnings, there's nothing suspicious in the log

I triggered it again, rebooted, then ran the command.

Comment 6 pigladal 2024-03-15 16:56:14 UTC

https://pst.innomi.net/paste/3kd9k94s3wbfoeaqjacdzq6g
Had another crash that may or may not be related after using the system for a few minutes after it was in sleep mode overnight. The screen went black for a second, then it came back for ~10 seconds with some areas looking garbled, then it went black again and the system was unresponsive, forcing me to reboot. These logs seem to contain more useful data.

Comment 7 pigladal 2024-03-18 19:52:39 UTC

Just replying to this saying that the bug seems to have gone away, I haven't had any issues with crashing using my second monitor anymore.