Registered Member
|
One thread is completely occupied by plasmashell. Known bug, or what can I do to support tracking?
Latest official release (Arch Linux), AFAIR it wasn't a problem before 5.3. |
Administrator
|
You may want to file a bug. A backtrace would be needed too, but I'm afraid you won't be able to provide one by the way Arch makes their packages (no debug information).
"Violence is the last refuge of the incompetent."
Plasma FAQ maintainer - Plasma programming with Python |
Registered Member
|
|
|
nvidia GPU?
tried "gdb --pid `pidof plasmashell`" to get a backtrace? (you'll have to "echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope" in order to be allowed to attach to processes unless you're root) |
Registered Member
|
Yes, nvidia.
Makes gdb sense without debugging info? |
|
Probably - it'll still tell you the function names where the threads are currently in
> thread apply all bt |
Registered Member
|
top:
sudo gdb --pid <plasmashell> https://paste.kde.org/p5bv82a5m PS: Right now, plasmashell crashed finally with a bug report. I pasted the output to https://paste.kde.org/pipjxwzsx (not enough info to report). |
|
You loaded plasmashell into gdb and then quit w/o dumping any information
However, the backtrace from the crash was "predictable", it aborts in thread #11
We've ongoing bugreports against KWin compositing about the nvidia blob doing "funny things™" when resuming from STR and now, since plasmashell sits on top of QML on top of OpenGL, similar things emerge there as well. Unfortunately, I can atm. just suggest to a) ensure to not use a framebuffer console: https://wiki.archlinux.org/index.php/GR ... ramebuffer b)
|
Registered Member
|
No success with "GRUB_TERMINAL_OUTPUT=console" (change is effective after reboot but plasmasheel takes 100% after suspend). Is this advice still relevant (BTW: May I challenge the idea to spam a hardly readable journal with each and every message from kwin and adding there a reference to a bug with >100 comments? Just from the user perspective...)
Many thanks for your support! |
|
The comment is still relevant, yes.
(the noop yield causes a busy wait causes the high CPU load in plasmashell as well) Stashing it in the unreadble journal wasn't exactly a decision It's something that "happened" during porting from SC4 to KF5. kDebug turned into qDebug and now qCDebug, but we've afaik no config GUI for the categorized debug out, so the usually rather "rare" warning is now stashed in the mass output of the -by default- enabled general debug (which is really meant for development) Also Qt went from ~/.xsession-errors to journald - and that journald is really the by *far* weakest item of the entire systemd stack isn't our fault either (Its really unusuable/useless, consider turning it into a jumppad for rsyslog) |
Registered Member
|
And it solves the problem! For those who don't want to go through all comments or dig the web:
|
|
"Solve" by "no more high cpu load" or by "plasmashell also actually repaints"?
|
Registered Member
|
I never had issues with repainting. Yes, the high CPU load after suspension is gone.
|
|
Hmmm... I'd have said that if plasmashell hangs (w/ 100% cpu load) and finally aborts in glSwapBuffers, it cannot actually paint anything (that doesn't affect other applications of course - only the desktop and its panels etc.)
|
Registered Member
|
Here (on openSUSE Tumbleweed) the cpu plasmoid itself caused this high plamashell cpu usage. Deleted that CPU plasmoid for the moment.
|
Registered users: Bing [Bot], Google [Bot], Sogou [Bot]