Okay, thanks. I'll see what I can collect.

GA-X79-UD5 Motherboard i7-3930K CPU
I know that the X79 chipset can cause some problems as I have used my setup as a Hackintosh for several years and had to solve a lot of hardware problems manually.

But the bug I have sounds very similar to this:
https://forums.opensuse.org/showthread. ... ions/page2

The mentioned Qt-Bug is the one I was searching for. But it seems to be solved since QT > 5.6. Debian/Ubuntu are using old stuff, but not that old.

A still existing bug is here: Launchpad Bug 1848771, found it while following this thread: Askubuntu: Unable to resume from suspend

Could you compare this with your system and problem?

[quote="koffeinfriedhof"]The mentioned Qt-Bug is the one I was searching for. But it seems to be solved since QT > 5.6. Debian/Ubuntu are using old stuff, but not that old.

A still existing bug is here: Launchpad Bug 1848771, found it while following this thread: Askubuntu: Unable to resume from suspend
Could you compare this with your system and problem?[/quotation]

After reading the linked bug reports, I think that the described bug is not related to my problem.

I created two plasmashell logs (one with crash, one without) by restart the plasmashell and log the output to a file with timestamps.

When comparing these files I noticed that the primary monitor switches four times (twice from the first to the second monitor and back), and immediately after these messages the output is different.
In the attached snipped the different messages start with the line "Oct 22 13:13:50 trying to show an empty dialog".

I actually don't think that Plasmashell really "crashes". It is more likely that it hangs (blocks). Otherwise I would see more error messages.

Code: Select all

Okt 22 13:13:47 Old primary output: QScreen(0x557f0792dd40, name="DisplayPort-1") New primary output: QScreen(0x557f091f52f0, name="DisplayPort-0")
Okt 22 13:13:47 kf.package: No metadata file in the package, expected it at: "/usr/share/wallpapers/EveningGlow/contents/images/"
Okt 22 13:13:47 kf.package: No metadata file in the package, expected it at: "/usr/share/wallpapers/EveningGlow/contents/images/"
Okt 22 13:13:47 kf.package: No metadata file in the package, expected it at: "/usr/share/wallpapers/EveningGlow/contents/images/"
Okt 22 13:13:47 kf.package: No metadata file in the package, expected it at: "/usr/share/wallpapers/EveningGlow/contents/images/"
Okt 22 13:13:47 kf.package: No metadata file in the package, expected it at: "/usr/share/wallpapers/EveningGlow/contents/images/"
Okt 22 13:13:47 kf.package: No metadata file in the package, expected it at: "/usr/share/wallpapers/EveningGlow/contents/images/"
Okt 22 13:13:49 org.kde.kscreen: Requesting missing EDID for outputs (85, 86)
Okt 22 13:13:50 trying to show an empty dialog
Okt 22 13:13:50 trying to show an empty dialog
Okt 22 13:13:50 file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:146:19: QML Loader: Binding loop detected for property "height"
Okt 22 13:13:50 file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:146:19: QML Loader: Binding loop detected for property "height"
Okt 22 13:13:50 file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:29: TypeError: Cannot read property 'enabledBorders' of null
Okt 22 13:13:51 file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:121: TypeError: Cannot read property 'x' of null
Okt 22 13:13:51 file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:135: TypeError: Cannot read property 'y' of null
Okt 22 13:13:51 kf.activities: Killing the consumer
Okt 22 13:13:51 trying to show an empty dialog
Okt 22 13:13:51 requesting unexisting screen 0
Okt 22 13:13:51 requesting unexisting screen 0
Okt 22 13:13:51 requesting unexisting screen 0
...

Edit:
I think it is related to some dual monitor issues: If the system triggers the monitor standby the second (older) monitor stays connected in standby mode and therefore is always present and detectable by the system. This will trigger some primary monitor and layout swaps which which could sometimes end in a blocker.
https://bugs.kde.org/show_bug.cgi?id=341497
https://bbs.archlinux.org/viewtopic.php?id=252181

The first bug is already resolved (the same issue as above).

I have another idea: Try deactivating the compositor before suspend and see if this would change anything. While reading through the links, I remember that I had a clock stucked while playing a game in fullscreen on the primary screen (my panels are on the second one to not be hidden by fullscreen stuff). This was «solved» by changing the OpenGL-setting in the compositors configuration. So, give it a try, perhaps it'll help.

With the suspended compositor (Alt+Shift+F12) I am not able to reproduce the crash.
I will do a long term test on that.

Edit (updated):
I played around with the compositor options and found out that it can cause a plasma crash during waking up from standby if vsync is set to Automatic.
I set vsync to Reuse screen content, as recommended on
https://people.freedesktop.org/~cbrill/ ... 2017-03-24
Since then I have not experienced any plasma problems (nor tearing)
Update: I have to switch off vsync (Option "Never") to prevent Plasma from crashing. All other options led sooner or later to a plasma crash.
Update 2: To prevent tearing I've enabled the "TearFree" Option of the amdgpu driver in /usr/share/X11/xorg.conf.d/10-amdgpu.conf --> https://linuxreviews.org/HOWTO_fix_screen_tearing

I will keep this configuration and keep this thread up to date.

Okay. it has been almost a week since I had a blocker on Plasma. So the probability is high that the problem is caused by the vsync option of plasma.
Bug reported: https://bugs.kde.org/show_bug.cgi?id=428450