Greetings,

it is now a reproducible fact that my Plasma session goes awry in two different
situations:

1. When I plug in a headphones+micro (LogiTech or Jabra) with a USB connector;

2. When I suspend my laptop using the "Moon" keyboard key.

In both cases my Plasma workspace session gets unresponsive as far as the
keyboard is concerned. Interestingly, the keyboard still catches strokes *only*
when I type the Ctrl+Alt+F2 sequence to get out of Plasma and reach a console.
In that console, I run htop and I can monitor that /usr/bin/kglobalaccel5 eats
almost a third of the CPU (37%). I tried to kill (9) the process but it is
recreated anew and eats the same amount of CPU.

Note that I also see a huge CPU consumption for the following processes:

/usr/lib/xorg/Xorg (63%)
/usr/sbin/rsyslogd (14%)
/lib/systemd/systemd-journald (10%)

Yeah, I know these percentages sum up to > 100 :-(

I have to to specify that the case 1. does not happen when I am running not
Plasma but Gnome (Wayland).

Should I install other packages to fix the problem? What can I do to help?

Sincerely,
Filippo

Hi Filippo,

I have noticed a similar behaviour. However, the behaviour has improved
significantly (at least for me) and in recent versions of
libkf5globalaccel-bin the CPU bursts after connecting e.g. a mouse with
a USB connector are only relatively short (a couple of seconds maybe
depending on your machine).

Could you try to run a recent KDE stack with testing or unstable and see
if the issue is still as bad ?

For some people, the issue was apparently caused by ~/.Xmodmap. Can you
check whether you have such a file ? Thank you.

Hi Filippo,

Two ideas related to this part of your report:

The sum-of-percentages being above one-hundred is likely due to a multi-CPU (or
perhaps multiple-core) system - I think that each percentage reported is for a
single processor.  If the total goes above 100 * x, where x is the number of
processors, then we're allowed to become more confused.  Let's not do that yet.

Focusing more on this line in particular -- and the fact that kglobalaccel was
(and still is, in 5.103.0-1) configured to auto-restart on unhandled error[1],
then I think it's possible that the process is failing and being recreated
rapidly.  Each occurrence of that should be logged in the system journal,
and that could cause high CPU usage for that service.

All a theory so far, but if you are able to replicate the behaviour (I realize
it has been a while since your report) then I would suggest taking a look at
the service logs in journalctl to see if there are any clues there, and let us
know.

Thank you,
James

[1] - https://sources.debian.org/src/kglobalaccel/5.78.0-3/src/runtime/main.cpp/?hl=92#L79

A summary of a side-discussion between Filippo and myself about this bug:

  * Although the bug doesn't appear reproducible today, the cause hasn't been
    confirmed.

  * We both agreed that it makes sense for bugs to continue to stay open until
    it's clear that the reported problem has been solved.

Based on that I think we should leave the bug open, but reduce the severity so
that it isn't considered release-critical for bookworm.

(this update is also partly to note that we haven't found any more information
yet)

Le 13 mars 2023 21:04:33 GMT+01:00, James Addison <jay@jp-hosting.net> a écrit :

Thank you for the follow up.

Agreed.