I know it is an old topic but I'm experiencing the same problems described in those posts on Kubuntu 20.10, Plasma 5.19.5
The problem exists since Kubuntu 19.04 and I have a Plasma restart script which I run each time it crashes with the hope that it will get fixed in the next release.
Here I am on Kubuntu 20.10 still with the same problem.

Usually the Plasma crashes when the (dual) monitors wake up from standby. I have auto login activated.
- The kwin replace command can not fix the problem when Plasma crashed. The Plasmashell process has to be killed and restarted to get a working panels etc...
- I've removed caches and plasmashell setting folders without success.
- I don't see any hint in any log files.
- The only thing I found out is, that plasma never crashed when I switched the composer to xRender.

Does anyone have a hint how I could identify the root of the problem?

Thank you
Bruzzlee

Did you try with a new user? There is likely something in your settings causing this, I haven't seen a Plasma crash on current Kubuntu 20.10 beta, nor on the previous 20.04.

Mamarok wrote:Did you try with a new user? There is likely something in your settings causing this, I haven't seen a Plasma crash on current Kubuntu 20.10 beta, nor on the previous 20.04.

Hi Mamarok
Thank you for your suggestion.
I just created a new user "sudo useradd -m testUser", started some applications (Firefox, Thunerbird, Latte Dock, Chromium) and kept it running until the inactivity caused a logout and monitor standby.
Result: Plasma was crashed after log in.
Everything with a complete new user. (And reboot directly into the new account)

As next I will test if Latte Dock might trigger something.

I can't imagine that there is no error log which I could activate to find the source of my problem...

Greetings
Bruzzlee

Hi!

What graphics card do you use?

Code: Select all

lspci -nnk | grep -A3 "\[03..\]:"


Logfiles are provided by systemd → `journalctl -b -xep 0..4` would print all warnings and errors since last reboot. See e.g. ArchWiki:journalctl for details.

koffeinfriedhof wrote:Hi!

What graphics card do you use?

Code: Select all

lspci -nnk | grep -A3 "\[03..\]:"


Logfiles are provided by systemd → `journalctl -b -xep 0..4` would print all warnings and errors since last reboot. See e.g. ArchWiki:journalctl for details.

Hi koffeinfriedhof

Thanks for the answer.

I use a Radeon RX 580 4GB AORUS GIGABYTE
On a GA-X79-UD5 Motherboard i7-3930K CPU

02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev e7)
Subsystem: Gigabyte Technology Co., Ltd Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1458:22fd]
Kernel driver in use: amdgpu
Kernel modules: amdgpu

I know about those log files. But I never saw a warning / error related to the crashes.

Perhaps you get more information about the crash if you set plasmashell to debug output. There is `kdebugsettings` to setup via GUI. You can also debug the kernel suspend in ubuntu like described at https://wiki.ubuntu.com/DebuggingKernelSuspend. Perhaps some messages lead to the underlying issue.

Basically a systemd using system runs is defined via systemd-sleep.target and `systemctl suspend` will trigger `/usr/lib/systemd/systemd-sleep suspend`. Configuration is in `/etc/systemd/sleep.conf`. Perhaps you can try out different „sleeps“ like the new „freeze“ or „hibernate“ instead of „suspend“ and see if it works (better).

Depending on your motherboard and cpu you could try out some acpi-kernel-options, or enable kernel-/system-debug. The kernel-parameters can be setup temporarily via GRUB2 as described here: https://wiki.ubuntu.com/Kernel/KernelBootParameters. Give acpi_osi="Linux" a try or "debug" for debugging kernel and system which will create a big dmesg-output.

First thing to find out will be if the system itself does a flawless wakeup (without the graphical environment). If this is working, you can switch over to the plasma-debug-stuff.


edit: About the „acpi_osi“ you can read here and try different options: ArchWiki:DSDT.

koffeinfriedhof wrote:Perhaps you get more information about the crash if you set plasmashell to debug output. There is `kdebugsettings` to setup via GUI. You can also debug the kernel suspend in ubuntu like described at https://wiki.ubuntu.com/DebuggingKernelSuspend. Perhaps some messages lead to the underlying issue.

Basically a systemd using system runs is defined via systemd-sleep.target and `systemctl suspend` will trigger `/usr/lib/systemd/systemd-sleep suspend`. Configuration is in `/etc/systemd/sleep.conf`. Perhaps you can try out different „sleeps“ like the new „freeze“ or „hibernate“ instead of „suspend“ and see if it works (better).

Depending on your motherboard and cpu you could try out some acpi-kernel-options, or enable kernel-/system-debug. The kernel-parameters can be setup temporarily via GRUB2 as described here: https://wiki.ubuntu.com/Kernel/KernelBootParameters. Give acpi_osi="Linux" a try or "debug" for debugging kernel and system which will create a big dmesg-output.

First thing to find out will be if the system itself does a flawless wakeup (without the graphical environment). If this is working, you can switch over to the plasma-debug-stuff.


edit: About the „acpi_osi“ you can read here and try different options: ArchWiki:DSDT.

Hi koffeinfriedhof
Thanks for the detailed tips! I will go through them step by step and report as soon as I have found hints that lead to the root of the problem.
Since the crash happens sporadically (not every sleep causes it), it may take some time to test everything.

Thank you for you help. This should definitely bring me closer to a solution.
Bruzzlee

bruzzlee wrote:

koffeinfriedhof wrote:Perhaps you get more information about the crash if you set plasmashell to debug output. There is `kdebugsettings` to setup via GUI. You can also debug the kernel suspend in ubuntu like described at https://wiki.ubuntu.com/DebuggingKernelSuspend. Perhaps some messages lead to the underlying issue.

Basically a systemd using system runs is defined via systemd-sleep.target and `systemctl suspend` will trigger `/usr/lib/systemd/systemd-sleep suspend`. Configuration is in `/etc/systemd/sleep.conf`. Perhaps you can try out different „sleeps“ like the new „freeze“ or „hibernate“ instead of „suspend“ and see if it works (better).

Depending on your motherboard and cpu you could try out some acpi-kernel-options, or enable kernel-/system-debug. The kernel-parameters can be setup temporarily via GRUB2 as described here: https://wiki.ubuntu.com/Kernel/KernelBootParameters. Give acpi_osi="Linux" a try or "debug" for debugging kernel and system which will create a big dmesg-output.

First thing to find out will be if the system itself does a flawless wakeup (without the graphical environment). If this is working, you can switch over to the plasma-debug-stuff.


edit: About the „acpi_osi“ you can read here and try different options: ArchWiki:DSDT.

Hi koffeinfriedhof
Thanks for the detailed tips! I will go through them step by step and report as soon as I have found hints that lead to the root of the problem.
Since the crash happens sporadically (not every sleep causes it), it may take some time to test everything.

Thank you for you help. This should definitely bring me closer to a solution.
Bruzzlee

Meanwhile I did some test with different settings and also enabled all debug options.
Today the plasamshell crashed again but this time I think I've found a hint in the log:

Code: Select all

17.10.20 13:10   fwupd   11:10:36:0053 FuEngine             synaptics_rmi failed to change udev device /sys/devices/pci0000:00/0000:00:02.0/0000:02:00.0/drm/card0: cannot ensure ID: FuUdevDevice:
17.10.20 13:10   fwupd   Unknown Device
17.10.20 13:10   fwupd     Flags:                none


The complete log during the crash time:
https://www.dropbox.com/sh/cfdzxeyx0h4s ... rP-oa?dl=0

Next I am investigating in the fwupd problem.

Greetings

_____________________
Edit:
It is not related to fwupd as I've uninstalled it and the crash still happens.

Did you upgrade from 19.10 to 20.04 (to 20.10) or did a clean install? Old installations still have Python2-packages on board. As Python2 is dead since January, you could remove all those packages.

Another thing could be wrong permissions in the home folder(s): Check with `find $HOME ! -user $USER -ls` which should not have any output. If it does you need to correct the permissions with `chown`.

But I cannot see anything related to a plasma shell crash in your logfile. There is a lot of KScreen-Debug stuff, mainly randr outputs, but nothing related to plasmashell or kwin.

koffeinfriedhof wrote:Did you upgrade from 19.10 to 20.04 (to 20.10) or did a clean install? Old installations still have Python2-packages on board. As Python2 is dead since January, you could remove all those packages.

Another thing could be wrong permissions in the home folder(s): Check with `find $HOME ! -user $USER -ls` which should not have any output. If it does you need to correct the permissions with `chown`.

But I cannot see anything related to a plasma shell crash in your logfile. There is a lot of KScreen-Debug stuff, mainly randr outputs, but nothing related to plasmashell or kwin.

Yes, I did the upgrade from 19.10.
I removed python2 now with

Code: Select all

sudo apt-get install python-is-python3
sudo apt-get autoremove --purge

"but nothing related to plasmashell or kwin." and this is exactly what bothers me.
I now try to play a bit with the Compositor. Testing XRender instead of OpenGL. etc.

Does the system wake up without errors in journalctl? You didn't mention the hardware-side (e.g. acpi errors after wakeup).

You can use `kdebugsettings` to enable plasmashells debug output - or just run it in a terminal using

Code: Select all

kquitapp5 plasmashell && kstart5 plasmashell

to get more messages.

koffeinfriedhof wrote:Does the system wake up without errors in journalctl? You didn't mention the hardware-side (e.g. acpi errors after wakeup).

You can use `kdebugsettings` to enable plasmashells debug output - or just run it in a terminal using

Code: Select all

kquitapp5 plasmashell && kstart5 plasmashell

to get more messages.

Hi koffeinfriedhof

As far as I see I don't have any acpi errors in journalctl. But I will recheck that.

Currently I am using the system while plasmashell is running in terminal as you suggested.
I could capture the output but I did not have time to go through it.
https://www.dropbox.com/s/a8wduttymz585 ... 0.txt?dl=0

Greeting
Bruzzlee

I've not read through all lines, but I found some entries which show that the memory management (RAM) is not correctly restored, as Plasma looses some Pointers. In short: a pointer is an address in memory with 64bits length that marks the starting point of some variables.
The next thing is the changing of DP-0/DP-1 with an invalid QScreen.
Further filtering and reading required, I just looked it up in the browser

There was a bug some years ago with QScreen, but I cannot really remember it. I'll do a search about this, finding out if this is still valid and will post the search result here.
Do you have another window manager or desktop environment installed on your kubuntu which we could use to test?

Okay, thank you very much for your investigations.
I currently have no other window manager or desktop environment installed, but I'm willing to do some testing if it helps the community.

I am not a developer or similar, just another user, so there is no need to install additional stuff. If you want to help the kde developers, the best will be filing a bug and add the informations provided by

Code: Select all

qdbus org.kde.KWin /KWin supportInformation

before and after a crash, including details of your machine.

To get additional information, you could kill the plasmashell and restart it before the suspending. So after a fresh boot use `kquitapp5 plasmashell && kstart5 plasmashell` in a Konsole window, set the buffering to unlimited and save the output to a file. Then watch the ouput after suspend or save it again. `journalctl -b -xep err` or `dmesg` could help too.

For now: What machine do you use? What chipset? This is independent of Plasma, but perhaps it could help. Some newer intel seem to have problems with suspend and hibernate, so the usual rule is to disable the powermanagement (which I would not recommend).