When waking up from suspend, Xorg uses 100% cpu for a few minutes and then it goes back to normal. The same thing also happens when switching between x servers. Using razor-qt + kwin I can not reproduce this. Asking in KDE forums I was told either plasma-desktop or kglobalaccel could be causing the issue. Setting up a pm-utils hook to kill kglobalaccel fixes the cpu usage on resume from sleep, but still an issue when switching between x servers. Reproducible: Always Steps to Reproduce: 1. Suspend to ram 2. Wake up 3. Or switch between x servers.
Hi, I have the same behaviour. After suspending or switching I have to kill kglobalaccel in order to use my system. Here you can find some info about my system: kde version 4.8.4 lspci -vv .... 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 03) Subsystem: Acer Incorporated [ALI] Device 0136 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 58400000 (64-bit, non-prefetchable) [size=1M] Capabilities: <access denied> /var/log/Xorg.0.log [ 28.263] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so [ 28.380] (II) Module intel: vendor="X.Org Foundation" [ 28.380] compiled for 1.12.3.902, module version = 2.19.0 [ 28.380] Module class: X.Org Video Driver [ 28.380] ABI class: X.Org Video Driver, version 12.1
Hi, I installed the debug package so I was able to catch two stack traces while having the problem: the first: #0 0xb773a424 in __kernel_vsyscall () #1 0xb765ed5b in poll () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0xb55ce7b0 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1 #3 0xb55d00f0 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1 #4 0xb55d03b7 in xcb_wait_for_reply () from /usr/lib/i386-linux-gnu/libxcb.so.1 #5 0xb6d8b8b2 in _XReply () from /usr/lib/i386-linux-gnu/libX11.so.6 #6 0xb6d79a09 in XGetModifierMapping () from /usr/lib/i386-linux-gnu/libX11.so.6 #7 0xb748e1a5 in KKeyServer::initializeMods () at ../../kdeui/util/kkeyserver_x11.cpp:508 #8 0xb772f7ea in KGlobalAccelImpl::x11MappingNotify (this=this@entry=0x83ebb48) at ../../kglobalaccel/kglobalaccel_x11.cpp:199 #9 0xb772fc88 in x11Event (event=0xbf91a86c, this=0x83ebb48) at ../../kglobalaccel/kglobalaccel_x11.cpp:171 #10 KGlobalAccelImpl::x11Event (this=0x83ebb48, event=0xbf91a86c) at ../../kglobalaccel/kglobalaccel_x11.cpp:164 #11 0xb7342673 in publicx11Event (e=0xbf91a86c, this=<optimized out>) at ../../kdeui/kernel/kapplication.cpp:918 #12 KApplication::x11EventFilter (this=0xbf91ac40, _event=0xbf91a86c) at ../../kdeui/kernel/kapplication.cpp:930 #13 0xb6431236 in qt_x11EventFilter (ev=0xbf91a86c) at kernel/qapplication_x11.cpp:435 #14 qt_x11EventFilter (ev=0xbf91a86c) at kernel/qapplication_x11.cpp:423 #15 0xb6440152 in QApplication::x11ProcessEvent (this=0xbf91ac40, event=0xbf91a86c) at kernel/qapplication_x11.cpp:3358 #16 0xb646b614 in x11EventSourceDispatch (s=0x826e020, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146 #17 0xb54a36d3 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #18 0xb54a3a70 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #19 0xb54a3b51 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #20 0xb5dd4831 in QEventDispatcherGlib::processEvents (this=0x8249780, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #21 0xb646b1fa in QGuiEventDispatcherGlib::processEvents (this=0x8249780, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #22 0xb5da101c in QEventLoop::processEvents (this=this@entry=0xbf91ab68, flags=...) at kernel/qeventloop.cpp:149 #23 0xb5da1311 in QEventLoop::exec (this=0xbf91ab68, flags=...) at kernel/qeventloop.cpp:204 #24 0xb5da6a8a in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1187 #25 0xb63b62f4 in QApplication::exec () at kernel/qapplication.cpp:3817 #26 0xb772094d in kdemain (argc=1, argv=0xbf91ad44) at ../../kglobalaccel/main.cpp:110 #27 0x0804861b in main (argc=1, argv=0xbf91ad44) at kglobalaccel_dummy.cpp:3 and the second: #0 0xb773a424 in __kernel_vsyscall () #1 0xb765ed5b in poll () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0xb55ce7b0 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1 #3 0xb55d00f0 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1 #4 0xb55d03b7 in xcb_wait_for_reply () from /usr/lib/i386-linux-gnu/libxcb.so.1 #5 0xb6d8b8b2 in _XReply () from /usr/lib/i386-linux-gnu/libX11.so.6 #6 0xb6d86ebb in XSync () from /usr/lib/i386-linux-gnu/libX11.so.6 #7 0xb73c5bf7 in KXErrorHandler::error (this=0xbf91a2f0, sync=true) at ../../kdeui/util/kxerrorhandler.cpp:102 #8 0xb772f574 in KGlobalAccelImpl::grabKey (this=0x83ebb48, keyQt=218103814, grab=true) at ../../kglobalaccel/kglobalaccel_x11.cpp:151 #9 0xb772bc76 in GlobalShortcutsRegistry::registerKey (this=0x83d1f48, key=218103814, shortcut=0x8400680) at ../../kglobalaccel/globalshortcutsregistry.cpp:321 #10 0xb772a33d in setActive (this=0x8400680) at ../../kglobalaccel/globalshortcut.cpp:221 #11 GlobalShortcut::setActive (this=0x8400680) at ../../kglobalaccel/globalshortcut.cpp:210 #12 0xb7728c03 in KdeDGlobalAccel::Component::activateShortcuts (this=0x83fd648) at ../../kglobalaccel/component.cpp:127 #13 0xb772ceb3 in GlobalShortcutsRegistry::activateShortcuts (this=0x83d1f48) at ../../kglobalaccel/globalshortcutsregistry.cpp:92 #14 0xb772f7fa in KGlobalAccelImpl::x11MappingNotify (this=this@entry=0x83ebb48) at ../../kglobalaccel/kglobalaccel_x11.cpp:202 #15 0xb772fc88 in x11Event (event=0xbf91a86c, this=0x83ebb48) at ../../kglobalaccel/kglobalaccel_x11.cpp:171 #16 KGlobalAccelImpl::x11Event (this=0x83ebb48, event=0xbf91a86c) at ../../kglobalaccel/kglobalaccel_x11.cpp:164 #17 0xb7342673 in publicx11Event (e=0xbf91a86c, this=<optimized out>) at ../../kdeui/kernel/kapplication.cpp:918 #18 KApplication::x11EventFilter (this=0xbf91ac40, _event=0xbf91a86c) at ../../kdeui/kernel/kapplication.cpp:930 #19 0xb6431236 in qt_x11EventFilter (ev=0xbf91a86c) at kernel/qapplication_x11.cpp:435 #20 qt_x11EventFilter (ev=0xbf91a86c) at kernel/qapplication_x11.cpp:423 #21 0xb6440152 in QApplication::x11ProcessEvent (this=0xbf91ac40, event=0xbf91a86c) at kernel/qapplication_x11.cpp:3358 #22 0xb646b614 in x11EventSourceDispatch (s=0x826e020, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146 #23 0xb54a36d3 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #24 0xb54a3a70 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #25 0xb54a3b51 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #26 0xb5dd4831 in QEventDispatcherGlib::processEvents (this=0x8249780, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #27 0xb646b1fa in QGuiEventDispatcherGlib::processEvents (this=0x8249780, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #28 0xb5da101c in QEventLoop::processEvents (this=this@entry=0xbf91ab68, flags=...) at kernel/qeventloop.cpp:149 #29 0xb5da1311 in QEventLoop::exec (this=0xbf91ab68, flags=...) at kernel/qeventloop.cpp:204 #30 0xb5da6a8a in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1187 #31 0xb63b62f4 in QApplication::exec () at kernel/qapplication.cpp:3817 #32 0xb772094d in kdemain (argc=1, argv=0xbf91ad44) at ../../kglobalaccel/main.cpp:110 #33 0x0804861b in main (argc=1, argv=0xbf91ad44) at kglobalaccel_dummy.cpp:3 (In reply to comment #1) > Hi, > > I have the same behaviour. After suspending or switching I have to kill > kglobalaccel in order to use my system. Here you can find some info about > my system: > > kde version 4.8.4 > > lspci -vv > .... > 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated > Graphics Controller (secondary) (rev 03) > Subsystem: Acer Incorporated [ALI] Device 0136 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0 > Region 0: Memory at 58400000 (64-bit, non-prefetchable) [size=1M] > Capabilities: <access denied> > > /var/log/Xorg.0.log > > [ 28.263] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so > [ 28.380] (II) Module intel: vendor="X.Org Foundation" > [ 28.380] compiled for 1.12.3.902, module version = 2.19.0 > [ 28.380] Module class: X.Org Video Driver > [ 28.380] ABI class: X.Org Video Driver, version 12.1
I have a custom .Xmodmap, after removing it, I have no more problem.
Hi, I can absolutely confirm this bug on Kubuntu 12.04.x (Qt:4.8.1; KDE: 4.8.5; KDE Global Shortcuts: 0.2). Occurrence on resume from suspend and hibernation as well as after switching X sessions. X-server (Xorg) under these circumstances always reproducibly consumes major CPU resources for several minutes. If I forget to avoid using keyboard shortcuts during this timespan, the system is rendered almost useless (keyboard or mouse input only accepted with huge delays) until Xorg stops hogging the CPU after said few minutes. Killing and restarting of kglobalaccel always ends this pest. And I can also confirm that this behaviour only occurs with a custom .Xmodmap present which I unfortunately am in need of. Thank you for your great work on my favorite desktop environment! :-)
I can also confirm this giant bug.. This bug basically renders ANY ONE's system that uses .Xmodmap completely useless any time they need to switch virtual terminals or any thing!!.. This bug happens EVERY time I turn on and off my monitor! And it happens EVERY time I switch to an other virtual terminal (pressing control+alt+F1 for instance).. Please some one fix this bug.. It basically makes it impossible to use .Xmodmap on KDE! This bug has been open for 2 years already.. I really need to use .Xmodmap on here..
Hi Baconmon, this to me was/is the most frigging annoying bug I can remember; I mean it was *reeeeaaally* pissing me off so much I could feel my stomach cringe each time it happened. In other words I had a strong incentive to find a remedy myself, since no progress could be spotted here. This is the solution I found. It works perfectly, but includes some work: You will have to modify your XKB config instead of using .Xmodmap, which will have to be renamed/removed afterwards or it will still trigger this bug. Unfortunately I can only give you general hints, as it's been some months now since I did this. Bad memory, sorry. This is the relevant documentation: http://madduck.net/docs/extending-xkb/ http://www.charvolant.org/~doug/xkb/html/index.html http://www.freedesktop.org/wiki/Software/XKeyboardConfig/ For my special needs I did have to alter or create the following files on Kubuntu: - I did use "/usr/share/X11/xkb/symbols/altwin" as a template for the new file "/usr/share/X11/xkb/symbols/altwin_${myconfig}" - "/usr/share/X11/xkb/symbols/${locale; i.e. en, fr, it, de, es}" as template for "/usr/share/X11/xkb/symbols/${locale}_${myconfig}" - change "/usr/share/X11/xkb/rules/evdev"; don't forget to backup this file i.e. as "/usr/share/X11/xkb/rules/evdev_original" - same with "/usr/share/X11/xkb/rules/evdev.lst" - ditto "/usr/share/X11/xkb/rules/evdev.xml" Just in case you might wonder what ${whatever} means, this is where you'll insert your individual filename. And remember to put the modified files into your backup routine or you'll be up to an unpleasant surprise sooner or later.
I fixed this problem finally.. Apparently xmodmap is the obsolete way of doing this any way now, and you should use the xkb way of doing it (kind of like smalldickbigego was saying).. This thread helped me edit the files I needed: https://askubuntu.com/questions/325272/permanent-xmodmap-in-ubuntu-13-04/347382 I am on debian stable (jessie) and I edited these two files (so I could modify 3 different keys): /usr/share/X11/xkb/symbols/pc and /usr/share/X11/xkb/symbols/keypad You might also need to change some of the other files depending on your locale and which keys you want to modify.. After that, I deleted .Xmodmap, then I restarted whole computer.. Now kglobalaccel finally doesn't freeze at 100% any more and I can still have customized keys!.. Of course this whole problem should also be obsolete when things transition to wayland instead of X that is eons old..
My desktop froze with high CPU usage whenever I connected a wacom table, webcam or bluetooth headphone. After a lot of debugging I traced it back to this bug and indeed I had an ancient .Xmodmap lying around. After deleting it everything worked again. See also https://unix.stackexchange.com/questions/546116/input-devices-stop-responding-and-high-x-org-and-kglobalaccel5-cpu-usage-when-co/547271
This bug may have not been fixed OR re-appeared As well as seeing this issue when plugging in a USB device I have 100% CPU usage when waking from suspend as the bug description says. Removing my ~/.Xmodmap prevented me from seeing this issue. Using up-to-date Plasma 5 on KDE NEON on 20.04 LTS base Please see here: https://forum.kde.org/viewtopic.php?f=309&t=165873&p=432142#p432142
I see the same issue with kglobalaccel-5.95.0 in plasma-desktop-5.25.0 on Gentoo, when launching the plasma session within TigerVNC server. kglobalaccel5 goes straight to 100% and has to be killed (after relaunching it behaves normally). I do NOT have an ~/.Xmodmap file.
(In reply to Robin Bankhead from comment #10) > I see the same issue with kglobalaccel-5.95.0 in plasma-desktop-5.25.0 on > Gentoo, when launching the plasma session within TigerVNC server. > kglobalaccel5 goes straight to 100% and has to be killed (after relaunching > it behaves normally). > > I do NOT have an ~/.Xmodmap file. I'm also experiencing this problem *very* often lately and I also do not have an ~/.Xmodmap file. Every time I login into my plasma session e.g. after a reboot kglobalaccel goes rogue and consumes 100% CPU of one CPU core and has to be killed manually. It also happens again after some time on normal desktop usage, or when not being on the computer at all for a while and comming back I often find kglobalaccel consuming 100% CPU again. Often I only realize this because of fan noise as it doesn't negativly affect my desktop usage. I never had this problem before and didn't change any configuration settings so I suppose it came with upgrades. However I've also no clue on how to debug this. It's certainly very annoying. Please let me know if there's any information I could provide to help finding the root cause. Operating System: Exherbo KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 Kernel Version: 5.18.1 (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2060 SUPER/PCIe/SSE2
*** This bug has been confirmed by popular vote. ***
I had the same issue on 2 Gentoo machines while using TigerVNC, but recently (either with frameworks 5.98 or some other package update) the issue is gone on both machines.
Correction: On first start kglobalaccel5 consumes 100% CPU. If killed and started again, it will behave properly. Before I had to kill it regularly. Now it seems I've killed it once and forgot about it.
FWIW, the issue as I outlined my experience of it is still occurring under kde-frameworks/kglobalaccel-5.97.0, but for the first time I have also encountered it recurring later in my VNC session. (It is possible it's happened previously, but I'm not normally physically near the machine during a session so might not notice). The only possible triggering action I can think of from that session was me toggling fullscreen in TigerVNC, which is set to resize the remote desktop to client window size (using xrandr - this would presumably happen on initial connection too as I don't have initial screen res set to match the client display I use). I'll try to reproduce this later to check.
Just to update on my earlier, I haven't found a way of re-triggering the high CPU usage after killing and relaunching kglobalaccel5 at the start of my VNC session, and it has not recurred again during such a session. (It's possible it has happened without me noticing though.) This is now under kglobalaccel-5.99.0, plasma-desktop-5.26.2.
(In reply to Robin Bankhead from comment #16) > Just to update on my earlier, I haven't found a way of re-triggering the > high CPU usage after killing and relaunching kglobalaccel5 at the start of > my VNC session, and it has not recurred again during such a session. (It's > possible it has happened without me noticing though.) > > This is now under kglobalaccel-5.99.0, plasma-desktop-5.26.2. I have a relatively reliable way to reproduce this issue, first of course as already known it happends on every login / plasma session start at least on X11 and requires a manual restart of the plasma-kglobalaccel user service to behave again: $ systemctl --user restart plasma-kglobalaccel.service This happens on another hardware machine with completely different graphical setup where I use Intel Iris mesa driver contrary to the NVIDIA proprietary one on my desktop, and I'm also able to reproduce this on VMware where my guest uses the SVGA3D driver so I don't think it has anything to do with the graphical stack per se. We also got reports from other users of our distribution experiencing the same. Now for being able to reproduce it in a running plasma session, it always happens to me when using Steam, not when playing regular games on the desktop itself but when using the Steam Link Android app on for example my TV (but should probably also work on a device like a phone to reproduce - not tested this myself yet though) to stream the games, when I come back to my desktop I can see the kglobalaccel5 process churning away with 100% again. To make it a little bit less annoying I've now setup KDE Connect to issue the above mentioned command so I'm able to remotly restart the service but it's still annoying as hell especially as I have no idea when it kicks in, it could also happend during playing and/or when restarting a game and influence the performance. I would still like to have some guidance on how to be able to debug the issue. Maybe for yet another workaround I'll gonna try adding something like e.g. CPUQuota=1% to the plasma-kglobalaccel.service [Service] section. Still, I'd would love to see this but get some attention from the maintainers who have some deeper knowledge what could be the root cause and how this issue materializes. Also I have no clue why it doesn't happend on e.g. a Fedora 36 KDE Plasma install next to me having more or less the identical hardware setup and also using an X11 session. Afaiks this issue started when the change over to systemd user units was made with a plasma update, but this is just a vague guess as I first thought it might be a issue on my machine and kept on killing the process manually until having time to search for bug reports and found this one. However since we're recycling an original issue from 2012 here it would've probably been better to create a new bugreport even if it's about the same outcome, the issue is most probably not the same as the original report here.
As mentioned above I'm on Gentoo, so no systemd involved here. And being in VNC I don't see it being graphics stack related either, but that's probably a bit above my pay-grade to say ;) I'm not sure either about taking some portion of the above off to a different bugreport. Right now we have a slightly disparate bag of seeming trigger-environments but a single unifying symptom. That the initial report is 10yrs old doesn't mean much. Unless more is done to show that the different cases are causing the same outcome for totally different reasons (and how many different ways can there actually be to drive a relatively simple process, like I imagine kglobalaccel5 is, into a CPU meltdown?) then I think the theory of a common cause holds water and it's therefore better if all the details remain in one place for the reference of whoever can input and maybe make a needed connection.
I can also confirm the problem with Gentoo and VNC remote X11 session (and I'm using systemd).
Created attachment 153617 [details] perf FlameGraph of the PID I added a perf FlameGraph of the process when it is stucked at 100% CPU. I don't know if it could help as the problem seems to be between QEventLoop and glib.
Created attachment 153618 [details] perf FlameGraph of the PID with a correct behaviour (0% CPU)
Further data point: I just added a systemmonitor plasmoid to my panel to show CPU usage, and interestingly after first opening my vnc session it actually did not show any heavy activity. It started maxing one core, however, as soon as I opened Yakuake (with a keyboard shortcut, natch). This sort of makes a lot more sense, even if it doesn't present a full diagnosis: I'm actually giving kglobalaccel itself some input that "upsets" it.
Sorry, amendment to the above on further investigation. The CPU spike is triggered by ANY keyboard input (e.g. typing a letter key, which opens the quick-launcher, or CTRL on its own which has no UI effect).
I've found a way to trigger the cpu thrash on-demand (when in VNC session). I noticed one of my custom shortcuts was triggering it every time, but on investigation it is not the shortcut but this command in the invoked script that actually causes it: xdotool key --clearmodifiers "shift+Left" I wonder if anyone can now deduce what is the common factor between the two triggering scenarios: 1. The first keyboard input of any kind in a new VNC session 2. Running xdotool to simulate keyboard events
A simple way to trigger the bug for me is to run: xmodmap ~/.Xmodmap_manual I had to rename .Xmodmap to .Xmodmap_manual to avoid the freezing of the machine upon every login. Now I only invoke xmodmap manually when I need it. Running the command above will freeze the machine for 20-30 seconds.
While certainly not a fix by any means I want to share a workaround because I found myself ever so often not noticing that the cpu spike again kicked in until I wondered why my machine is loud again and revving up the fans. I installed monit and dropped a configuration file in /etc/monit.d/ which monitors the process kglobalaccel5 and restarts it under my user session when two consecutive checks find the kglobalaccel5 process running with higher cpu usage than usual/normal: /etc/monit.d/kglobalaccel5 check process kglobalaccel5 matching "kglobalaccel5" start program = "/usr/bin/systemctl --machine tgurr@.host --user start plasma-kglobalaccel.service" stop program = "/usr/bin/systemctl --machine tgurr@.host --user stop plasma-kglobalaccel.service" restart program = "/usr/host/bin/systemctl --machine tgurr@.host --user restart plasma-kglobalaccel.service" if cpu usage > 10% for 2 cycles then restart You may have to adjust the systemctl path and the user of course and it only works for one user this way. For me this means I don't have to manually care about monitoring the process anymore and not having to issue the restart command after every single login all the time. journal entries should look something along the line like: Sep 25 20:25:05 exherbo monit[2412]: 'kglobalaccel5' process is running with pid 2457 Sep 25 20:25:05 exherbo monit[2412]: 'kglobalaccel5' cpu usage of 32.7% matches resource limit [cpu usage > 10.0%] Sep 25 20:25:34 exherbo monit[2412]: 'kglobalaccel5' cpu usage of 33.9% matches resource limit [cpu usage > 10.0%] Sep 25 20:25:34 exherbo monit[2412]: 'kglobalaccel5' trying to restart Sep 25 20:25:34 exherbo monit[2412]: 'kglobalaccel5' restart: '/usr/bin/systemctl --machine tgurr@.host --user restart plasma-kglobalaccel.service' Hope it may be useful for someone else as well.
I have the same problem of /usr/bin/kglobalaccel5 running at 100 % on one of 8 cpu cores. This happens since I installed Citrix two days ago, from: https://www.citrix.com/downloads/workspace-app/ https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html https://docs.citrix.com/en-us/citrix-workspace-app-for-linux/install with the two Debian packages: net/main/ctxusb utils/main/icaclient With some of the error reports above mentioning usb, I suppose that the "ctxusb" package causes the problem. Hope this helps in figuring out the reason. Would be glad to have this fixed in a future version :-) Citrix client installed in /opt/Citrix/ICAClient/ Software: KDE-Plasma-Version: 5.27.5 KDE-Frameworks-Version: 5.103.0 Qt-Version: 5.15.8 Kernel-Version: 6.1.0-13-amd64 (64-bit) Grafik-Plattform: X11 Hardware: Prozessoren: 8 x Intel Core i7-10510U CPU 1.80 GHz Speicher: 15,3 GiB RAM Grafikprozessor: Mesa Intel UHD Graphics Thanks, Christian