OSDIR suggests that the issue is in a call in _nv014tls () from /usr/lib/libnvidia-tls.so
The problem is that when you close konsole (easier to trigger if multiple tabs are open, at least so it seems) konsole keeps running in the background, consuming up to 100% of one CPU core. It keeps running until you kill it.
Switching to nouveau resolves the issue, it doesn’t occur with non-nvidia GPUs.
I am also affected by this bug, using 355.11 on Gentoo Linux (x86_64), but it looks like various distributions (Kubuntu, Gentoo, Arch Linux …) are affected.
nvidia bug report will be atached later, as I am currently not at home.
Thanks for looking into this and fixing it, as this has a terrible impact on the battery for nvidia laptop users.
I’m also affected by this. Same steps apply. Also on Gentoo x64.
different problem##
Foxi, could you also check if you also got a redrawing problems of fullscrenn Opengl windows when you Alt-Tab out of them and after a while (a few seconds) back…?
So you open an fullscreen OpenGL window and then when OpenGL takes over alt Tab out of it. Result, Windows does not get redrawn, aka picture freeze. This happens for exaple with Boderlands 2 and Kerbal Space Programm.
This is affecting me and i will write a second report for this soon.
Unfortunately this bug is still present with 358.09,
please fix it nvidia engineers, this is draining my laptop battery and overheating my CPU, it’s not really fun.
Can you take a look at it please ? It’s (virtually) impossible to debug the nvidia’s libs because there is no debuginfo or source code available due to the proprietary nature of the driver.
I can confirm this bug exists in Fedora 23/KDE spin. I am suspicious of a threading issue, but I don’t know if the nVidia driver just causes the issue to show up this way or if there is some other fundamental cause.
From what I’ve seen it may not be the nVidia driver which is at fault. There seems to be a complicated threading issue which might or might not be caused by the driver…it may just be this driver exposes the issue differently.
I’ve noticed that on some occasions under the nVidia driver starting a konsole results in the graphics underneath the konsole being what konsole starts with, and the graphics never refreshes for this one widget. You can still manually type things into the konsole and side-effects show the konsole actually works…graphics just doesn’t show, and is frozen in time. During that time konsole CPU use does not go up and is normal.
Killing a konsole can result in CPU use going up to 100% on one core, and the konsole PID does not go away…the konsole did not truly die. This seems to be a case of refresh being blocked and waiting, until death, and then something is unblocked and starts churning away at 100% waiting for some part of the application to respond, but that part no longer exists.
On the nouveau driver my system is completely unusable under KDE. Nouveau has so many places where it never refreshes and leaves graphics stale until I do something to manually force refresh that I would completely give up on KDE if I had to use nouveau. On the other hand, even nouveau issues could be the same threading issue, but timing and other influences changing how the issue shows up.
There also seems to be an issue related to D-bus which may or may not be related. D-bus is used to communicate between applications, and there is a bug whereby D-bus is not providing the same behavior to someone directly logged in on KDE versus logging in to KDE and then using “sudo --user= app_name”. Sometimes applications will fail to provide normal text on mouse hover-over help hints…the text is there but white on white, which is essentially invisible. Running the same application with “sudo --user=” mysteriously “fixes” some of those mouse hover over help hints to actually use the intended colors and not be invisible. Why would sudo of self fix something? Looking at D-bus messages shows D-bus may be at fault. This may or may not be related to refresh issues as well, and could perhaps change the nature or timing of threading bugs (the konsole 100% on a core I believe is threading, but distributed communication between threads is a heavy influence).
The biggest problem is that even if the nVidia driver is not doing this, it’s probably debugging through the driver which would be required to locate the issue. Threading issues are already notoriously difficult to debug, but the driver is probably where the debugging has to start. Throwing a session on a debugger and getting a konsole which doesn’t refresh or fails to go away upon death would answer a lot of questions very quickly.
Just an update. I’ve been using driver release 352.79 now for a while, and the issue of a konsole starting at 100% CPU or being unable to refresh seems cured. There are sometimes issues still with konsole churning at 100% upon exit. I suspect those issues which remain are not driver related, although this is not a guarantee (threading cleanup can be complicated).
The reason the bug disappeared in 361.16 was because of GLVND. 361.28 disables GLVND by default and as such brings the bug back. If you install 361.28 with GLVND, the problem will go away again.
Confirming this on latest Kubuntu 15.10 updates. Other than the CPU being throttled at full speed being stuck at a 100% konsole process I also noticed a huge amount of RAM being used (almost all of my 16 GiBs) and swap.
I’ll try what @mamarley said (thanks!) but it would be nice to see this bug fixed again in the next release.
I see this too on Kubuntu 16.10 (Qt 5.6.1) and NVIDIA 340 (Quadro FX 570). Did not see it with Kubuntu 16.04 with previous Qt (5.5.x), same hardware and still NVIDIA 340. Bug goes away with noveau drivers (that have other issues on their own).
Which kernel and nVidia driver version are you using? Starting with 352.63 the problem went away for me (I’m using Fedora 23 though, not Ubuntu). Currently I’m using 367.44 with a 4.7.9 Fedora kernel.