plasmashell crashes

V

VulcanRidr

I'm having a bit of a problem on my laptop. I run FreeBSD, just upgraded from 14.3 to 15 yesterday. So both systems run kde/plasma 6.5.x on X11 (just upgraded from 6.5.3 to 6.5.4 last night).
or
On my desktop, (Ryzen 7 5800x, 64GB RAM, nVidia RTX3060Ti), everything runs perfectly. The problem occurs on my laptop, which is a Lenovo Thinkpad W520, with the i7-2760QM, 32GB of RAM, and although it has an optimus setup, the intel GPU is enabled and the nVidia discrete GPU is disabled in bios. I also made sure the nvidia drivers were removed.

So what I am seeing is that while I am using the laptop, it is fine. However, when I stop using it, either closing the lid, or running an errand, when the screen blanks and comes back, I am able to move the mouse, but the the mouse buttons and keyboard are inoperative within the X session, and clicking a terminal window, mouse tab, etc., does not shift focus...The system, when it is working as expected, is using about 5MB (16%) of RAM. However, after running with the lid closed over night, idling, and the memory usage goes above 65%.

The problem can be fixed by jumping to one of the VTs and restart the login manager. I have tried switching that between SDDM and SLIM, and it occurs in both. As far as I know, plasmashell continues to run, but most times I get two core dump files in my home directory:

Code: 
-rw-------  1 1001 1001 20951040 Dec 14 16:56 drkonqi.core
-rw-------  1 1001 1001 22335488 Dec 14 17:18 plasmashell.core[CODE]

gdb on the plasmashell core shows

[CODE]Core was generated by `/usr/local/bin/plasmashell'.
Program terminated with signal SIGABRT, Aborted.
Sent by thr_kill() from pid 38293 and user 1001.
#0  0x000000085f3c79ea in ?? ()
[Current thread is 1 (LWP 102176)]

and the one on the drkonqi core:

Code: 
Core was generated by `/usr/local/lib/libexec/drkonqi --qtversion 6.9.3 --kdeframeworksversion 6.20.0 -'.
Program terminated with signal SIGABRT, Aborted.
Sent by thr_kill() from pid 26747 and user 1001.
#0  0x0000000845e539ea in ?? ()
[Current thread is 1 (LWP 106754)]

Unfortunately, I am a sysadmin, and not a programmer, so I have no experience with debugging core dumps.

Has anyone got any suggestions on a possible cause? Note that I did not see this problem when running 14.2, however when I upgraded to 14.3 and then 15.0, it has been happening with regular frequency.

Thanks
--vr
 
Interesting, I am having the same problem on both of my Thinkpad laptops, An E540, and a T440. Both since upgrading to 14.3 and with fresh installs of 15.0. Sorry I can't be of much help, but am following this to see if someone can shed some light. I can also restart plasma session from a VT. My laptops both have Intel graphics.

X
 
xenofruit said:
Interesting, I am having the same problem on both of my Thinkpad laptops, An E540, and a T440. Both since upgrading to 14.3 and with fresh installs of 15.0. Sorry I can't be of much help, but am following this to see if someone can shed some light. I can also restart plasma session from a VT. My laptops both have Intel graphics.

X
Click to expand...
Hey Xeno,

You know, I have monitoring set up on my homelab, and one thing I noticed is that, for example, if I am using it of an evening, memory is sitting somewhere between 15 and 25% utilization. I close the lid when I am done using it. The next morning, memory is ~70% used even though the system was idling.

Well last night, I killed firefox before closing the lid, and today, memory is at 17.1%. I have not been able to get to the laptop to check it, but I suspect it will be working. So maybe an interaction between firefox and plasmashell?

BTW, how are you restarting plasmashell from the VT? I tried and it said "could not connect to session"
 
VulcanRidr said:
I have not been able to get to the laptop to check it, but I suspect it will be working. So maybe an interaction between firefox and plasmashell?
Click to expand...
That is a big nope. Opened the lid, and had mouse ball control, but no clicky and no keyboard. Had to restart sddm.

I'm considering a) reinstalling kde, b) creating a new user and seeing if the problem occurs with a different user, or c) going back to 14.2 to see if it still occurs there, then upgrading to 15.0 directly.
 
VulcanRidr said:
Hey Xeno,

You know, I have monitoring set up on my homelab, and one thing I noticed is that, for example, if I am using it of an evening, memory is sitting somewhere between 15 and 25% utilization. I close the lid when I am done using it. The next morning, memory is ~70% used even though the system was idling.

Well last night, I killed firefox before closing the lid, and today, memory is at 17.1%. I have not been able to get to the laptop to check it, but I suspect it will be working. So maybe an interaction between firefox and plasmashell?

BTW, how are you restarting plasmashell from the VT? I tried and it said "could not connect to session"
Click to expand...
Well I don't use Firefox, I use chromium.... Anyway, I just go to a VT and run htop then kill plasma-session and it automatically take me back to the login screen (SDDM). I'm not too good at understanding crash dump reports, but next time it happens, I'll make a note of what's using high memory in htop.
 
xenofruit said:
Well I don't use Firefox, I use chromium.... Anyway, I just go to a VT and run htop then kill plasma-session and it automatically take me back to the login screen (SDDM). I'm not too good at understanding crash dump reports, but next time it happens, I'll make a note of what's using high memory in htop.
Click to expand...
Yeah, same as I do. I just restart sddm from thr VT. But the fact that you use chromium and I use firefox is a data point, thank you for that.
 
VulcanRidr said:
Yeah, same as I do. I just restart sddm from thr VT. But the fact that you use chromium and I use firefox is a data point, thank you for that.
Click to expand...
So I think it is kwin that is the culprit. When the screen becomes unresponsive, kwin seems locked up. I cannot kill kwin from a VT using htop. I'm still looking for more info on this sort of problem.

X
 
xenofruit said:
So I think it is kwin that is the culprit. When the screen becomes unresponsive, kwin seems locked up. I cannot kill kwin from a VT using htop. I'm still looking for more info on this sort of problem.

X
Click to expand...
By the way, I'm using X11, not Wayland. Is that true for you as well?
 
xenofruit said:
So I think it is kwin that is the culprit. When the screen becomes unresponsive, kwin seems locked up. I cannot kill kwin from a VT using htop. I'm still looking for more info on this sort of problem.

X
Click to expand...
Interesting. I'm wondering what else is going on. I just checked and kwin is owned by my user.

xenofruit said:
By the way, I'm using X11, not Wayland. Is that true for you as well?
Click to expand...
It is. Wayland has too many broken bits in it for my liking.

Now having said that, I am wondering if KDE has something that is using some of the broken wayland bits internally since they have doubled down on pushing the wayland agenda.

I was actually kicking around the idea of the spinning off a BE and trying to replace xorg with xlibre.

Was also thinking about booting back into my last 14.2 BE, and testing there, then trying to upgrade directly from 14.2 -> 15.0 and see if that makes a difference.
 
VulcanRidr said:
Interesting. I'm wondering what else is going on. I just checked and kwin is owned by my user.


It is. Wayland has too many broken bits in it for my liking.

Now having said that, I am wondering if KDE has something that is using some of the broken wayland bits internally since they have doubled down on pushing the wayland agenda.

I was actually kicking around the idea of the spinning off a BE and trying to replace xorg with xlibre.

Was also thinking about booting back into my last 14.2 BE, and testing there, then trying to upgrade directly from 14.2 -> 15.0 and see if that makes a difference.
Click to expand...
Yes, I think Plasma 6 was designed with Wayland as its primary target. I'm thinking the problem is the between kwin and some graphics driver bit....but my skills are not yet there to track it down,
 
xenofruit said:
Yes, I think Plasma 6 was designed with Wayland as its primary target. I'm thinking the problem is the between kwin and some graphics driver bit....but my skills are not yet there to track it down,
Click to expand...
Which would make it make sense why it is only occurring on our laptops. My desktop doesn't have intel, I have an nvidia 3060ti, and don't see these problems... So I am also wondering if it may be something with the DRM drivers.
 
My comment that mentioned and linked to Lumina Desktop was removed. Oops, sorry if I broke a forum rule...unintentional. Not sure what rule I broke though. I'm a noob, so there's that. 🙂
 
xenofruit said:
My comment that mentioned and linked to Lumina Desktop was removed. Oops, sorry if I broke a forum rule...unintentional. Not sure what rule I broke though. I'm a noob, so there's that. 🙂
Click to expand...
Not sure. Lumina is still supported, FreeBSD "native", and ZFS friendly. I personally know one of the devs that works on it.
 
VulcanRidr said:
Not sure. Lumina is still supported, FreeBSD "native", and ZFS friendly. I personally know one of the devs that works on it.
Click to expand...
Maybe a moderator will stop in and let me know. In other news, I think I'm making progress on the freeze problem. I believe I've narrowed it down to either a conflict with the drm-kmod mismatch....the kernel is looking for a particular version, but the drm-kmod meta configures the wrong one. Or it may have to do with gpu power management issue, where the driver tried to put the GPU into "low power mode during periods of inactivity, which somehow causes kwin to hang the split second the mouse is moved or keyboard is pressed. ....I'm still working on either of those two avenues.
 
xenofruit said:
Or it may have to do with gpu power management issue, where the driver tried to put the GPU into "low power mode during periods of inactivity, which somehow causes kwin to hang the split second the mouse is moved or keyboard is pressed. ....I'm still working on either of those two avenues.
Click to expand...
Merry Christmas!

I'm thinking this may be the right path...When I flip over to restart sddm, I have seen in my VT:

Code: 
drmn0: [drm] GPU HANG: ecode 6:1:85fffffc, in Renderer [127987]
drmn0: [drm] Resetting chip for stopped heartbeat on rcs0
drmn0: [drm] Renderer[127987] context reset due to GPU hang

Dec 22 13:55:11 danube pulseaudio[2927]: [] module.c: Failed to load module "module-x11-xsmp" (argument: "display=:0 xauthority=/tmp/xauth_WBmPlQ session_manager=local/danube:/tmp/.ICE-unix/2931"): initialization failed.
drmn0: [drm] GPU HANG: ecode 6:1:c07fffff, in MainThread [101015]
drmn0: [drm] Resetting chip for stopped heartbeat on rcs0
drmn0: [drm] Xorg[101015] context reset due to GPU hang

Note that the pulseaudio pops up all the time (though sound works on the laptop, but Iwas concerned about the initialization failure thing), but I occasionally get the GPU HANGs. Usually when I do, I will start seeing artifacts on my desktops.

I have also seen these in my logs:

Code: 
Dec 22 13:55:11 danube org.kde.powerdevil.discretegpuhelper[2972]: Detected locale "C" with character encoding "US-ASCII", which is not UTF-8. Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead. If this causes problems, reconfigure your locale. See the locale(1) manual for more information.

Which, ironically, happened at the same time as the pulseaudio thing above happened, though pulseaudio is not in the logs...

Are you seeing any of this in the logs or on the VTs, Xeno? I have stopped powerdxx, just to see if it affects the behavior.
 
I'll have to look at the logs.....what logs are you referring to? I'm not used to reviewing logs but I suppose I should be doing that to at least learn more.

I have managed to stop the problem by turning off all KDE power settings or setting them to 'never". But that of course means the screen is on all the time and nothing dims or sleeps. Chat GPT tells me its the handshake between the FreeBSD 14.3 and 15.0 kernel and KDE power saving that gets hung. Of course Chat GPT can be right or it can be very wrong....so I'm still poking around.
 
xenofruit said:
I'll have to look at the logs.....what logs are you referring to? I'm not used to reviewing logs but I suppose I should be doing that to at least learn more.
Click to expand...

The pulseaudio hangs and the GPU hang messages are showing up on VT1 when I got to restart sddm. The other stuff, /var/log/messages is a good place to start, and depending on what you are looking for, the various other logs could provide more information...In this case, /var/log/daemon.log has some information as well...Am seeing some power related items in the daemon.log too.

xenofruit said:
I have managed to stop the problem by turning off all KDE power settings or setting them to 'never". But that of course means the screen is on all the time and nothing dims or sleeps. Chat GPT tells me its the handshake between the FreeBSD 14.3 and 15.0 kernel and KDE power saving that gets hung. Of course Chat GPT can be right or it can be very wrong....so I'm still poking around.
Click to expand...

I think we are coming to the same conclusion from different directions. I stopped the powerdxx service on the command line to see if it works, and in KDE system settings, I set brightness to 100%, and set dim automatically to never. I'll start with those settings and see how it behaves.

I don't know that I trust chatgpt or ai in general, but if it seems valid, maybe a bug report should be opened with FreeBSD.
 
Powerdevil will restart at the next login. Just disable kde power management in system settings, as mentioned in other threads this is the only thing that works. It has been like this since...forever.
 
VulcanRidr said:
The pulseaudio hangs and the GPU hang messages are showing up on VT1 when I got to restart sddm. The other stuff, /var/log/messages is a good place to start, and depending on what you are looking for, the various other logs could provide more information...In this case, /var/log/daemon.log has some information as well...Am seeing some power related items in the daemon.log too.



I think we are coming to the same conclusion from different directions. I stopped the powerdxx service on the command line to see if it works, and in KDE system settings, I set brightness to 100%, and set dim automatically to never. I'll start with those settings and see how it behaves.

I don't know that I trust chatgpt or ai in general, but if it seems valid, maybe a bug report should be opened with FreeBSD.
Click to expand...
The trick to getting good results with chatgpt or other ai, is: Trust and Verify :-/😁 Asking it to double check its results gets more accrate results. Also, I often have to keep reminding it that my question is for freebsd.....as it "forgets" sometimes in the middle of a conversation and starts giving answers about linux.

Anyway, it suggested some lines to add to /boot/loader.conf, /etc/sysctl.conf, and ~/.config/kwinrc
I'm still testing these fixes. I'll post them if any of them work.

Chatgpt thinks that starting with FreeBSD 14.3, the kernel more aggressively wants to handle the power management, and fights with the KDE Plasma power management, causing kwin to hang. Unfortunate, since KDE was running smooth as butter with FreeBSD 14.2
 
fmc000 said:
Powerdevil will restart at the next login. Just disable kde power management in system settings, as mentioned in other threads this is the only thing that works. It has been like this since...forever.
Click to expand...
If you disable it in /etc/rc.conf, setting powerdxx_enable="NO", it should never start.
xenofruit said:
Interesting. I've never had this problem on this laptop until 14,3 and 15,0
Click to expand...
Same. Only started behaving this way on 14.3, and I started using FreeBSD about 9.3... The upgrade to 14.3 was when this behavior started occurring. I still have a 14.2 BE around, I just haven't had a chance to go back and verify (though Xeno just verified it for me).
xenofruit said:
Unfortunate since KDE was running smooth as butter with FreeBSD 14.2
Click to expand...
Agreed. Gnome has gone to the dark side (systemd and wayland), and now it appears that KDE/Plasma is going that route as well. Lumina may be an option, or I am hoping that (since i have been running kde for over 20 years) sonic desktop will take hold/end up in FreeBSD...
 
VulcanRidr said:
If you disable it in /etc/rc.conf, setting powerdxx_enable="NO", it should never start.
Click to expand...
I'm afraid you're mixing things. powerdxx is FreeBSD power management and it has nothing to do with powerdevil, which is a KDE thing that you cannot control via rc.conf .
 
You must log in or register to reply here.
Back
Top