Compiz running on Intel Haswell GPU has 100% CPU usage when computer is locked

Bug #1322751 reported by Benjamin Xiao on 2014-05-23
This bug affects 34 people
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)

Bug Description

I have Ubuntu 14.04 installed on a Lenovo X1 Carbon series 2. Whenever I lock my screen, compiz's CPU usage goes through the roof and it causes the CPU fan to spin up to max speed. I SSH'ed into the machine while it was locked to verify that it was indeed the compiz process causing the high cpu usage. When I unlock my computer, everything goes back to normal.

I've looked at, which seems related but that is for fglrx. This laptop has an Intel Haswell gpu.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: compiz 1:0.9.11+14.04.20140423-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64

ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Fri May 23 14:01:48 2014
DistUpgraded: Fresh install
DistroCodename: trusty
DistroVariant: ubuntu
 Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:2218]
InstallationDate: Installed on 2014-05-15 (8 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
MachineType: LENOVO 20A8S0UU00
PackageArchitecture: all
 PATH=(custom, no user)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic.efi.signed root=UUID=3bc1f0cb-5a0d-45e6-a19a-ba71b7bc4c84 ro quiet splash vt.handoff=7
SourcePackage: compiz
UpgradeStatus: No upgrade log present (probably fresh install) 03/26/2014
dmi.bios.vendor: LENOVO
dmi.bios.version: GRET36WW (1.13 )
dmi.board.asset.tag: Not Available 20A8S0UU00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50510 Pro
dmi.chassis.asset.tag: CS0000064833
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrGRET36WW(1.13):bd03/26/2014:svnLENOVO:pn20A8S0UU00:pvrThinkPadX1Carbon2nd:rvnLENOVO:rn20A8S0UU00:rvrSDK0E50510Pro:cvnLENOVO:ct10:cvrNotAvailable: 20A8S0UU00
dmi.product.version: ThinkPad X1 Carbon 2nd
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.11+14.04.20140423-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.52-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.1.0-4ubuntu5
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.1.0-4ubuntu5
version.xserver-xorg-core: xserver-xorg-core 2:1.15.1-0ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3.1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.910-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2
xserver.bootTime: Fri May 23 10:55:01 2014
xserver.configfile: default

xserver.logfile: /var/log/Xorg.0.log
 product id 61457
 vendor DEL
xserver.version: 2:1.15.1-0ubuntu2

Benjamin Xiao (ben-r-xiao) wrote :
Benjamin Xiao (ben-r-xiao) wrote :

I have more information about this bug. It seems like this only happens when Google Chrome is running and it has a tab that's flashing (flashing animation occurs when the tab has a notification, like when Gmail receives a new email or chat). If there is no tab flashing, then CPU usage is normal when screen is locked. The moment a tab starts flashing when the screen is locked, CPU usage skyrockets.

Steps to reproduce:

1.) Launch Google Chrome
2.) Load Gmail in a tab
3.) Lock the screen
4.) SSH into your machine from another machine to look at CPU usage using top.
5.) Send an email to yourself to start tab flashing animation.
6.) See CPU usage of compiz skyrocket in top.
7.) Unlock the screen and see CPU usage of compiz drop.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in compiz (Ubuntu):
status: New → Confirmed
Maksim Lin (maks-j) wrote :

Yep see exactly the same thing here on a Dell Latitude 7440 with Haswell i7 4600U.

As an extra data point, I'm running a newer kernel:
uname -a
Linux e7440 3.15.0-031500rc2-generic #201404201435 SMP Sun Apr 20 18:36:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Benjamin Xiao (ben-r-xiao) wrote :

Still seeing this behavior on 15.04 alpha

Philipp (c-ubuntu-f) wrote :

I can also confirm this behavior on a Lenovo Thinkpad T440s (Haswell Core i7-4600U) with the 15.04 alpha and the default kernel.
I think this should be rated critical because it can cause computers to overheat and cause damage to the hardware.

Philipp (c-ubuntu-f) wrote :

The problem still occurs in 15.04 with kernel 3.19.0-21 and Compiz :

fcole90 (fcole90) wrote :

As part of the big bug clear up for 16.04 we have reviewed this bug and we will not be working on it in the near future. Sorry we can't offer you a fix. We will of course review patches if anyone submits them. Please stop by IRC to discuss this option.

tags: added: desktop-bugscrub-wontfix
Michiel (michielhaisma) wrote :

I have it too on 15.10 beta, 4.2.0-16-generic, Ivy bridge Intel® Core™ i5-3230M CPU

V-Mark (vertesmark) wrote :

I faced exaclty the same problem with my system.
I already reported ad bug, now linked to this bug as duplicate.

Again, I confirm (for me):
- When I switch off "screen lock" and wait for screen fades out problem does NOT happen.
- In contrast if I lock screen manually (eg.: Alt-Ctrl-L or xdg-screensaver lock from x-terminal) compiz occupies one core 100%. Due to this fan starts.

I also tested: the
but it does not solve my problem, because compiz 100% CPU usage is not linked with power saving of monitor, but lock screen.

My data:
- Fresh install of Ubuntu 15.10 (plus some other non-desktop or gnome related packages)
- All energy consumption related settings are default (I have not changed them till now).
- Laptop: ACER Aspire V3-371
- CPU: Intel Core i5-5257U
- GPU: Intel Iris grapics 6100
- Display: 1920x1080 internal laptop display, no other display ever plugged in.
- 8G RAM
- 120G SSD

V-Mark (vertesmark) wrote :

Just answering "Benjamin Xiao (ben-r-xiao) wrote on 2014-05-24"-s post.

Unfortunately my problem is much wider.
BTW my processor is in the "Broadwell" family with is the successor or "Haswell" family.

To reproduce my problem:
- Switch on computer.
- log in and lock the screen (Alt+Ctrl+L)
- Press switch to virtual text terminal (eg.: Alt+Ctrl+1)
- use "top" to see what happening.

compiz goes to 100% using one core.
Checking CPU by CPU - hit "1" during running "top":
One core works 30% user 70% system, other 99,9% idle.

It IS very pity that nobody cares this issue, because quite decent systems with the latest Ubuntu is affected.

V-Mark (vertesmark) wrote :

Till devs do not find a real solution I made a BLOODY BRUTAL workaround which helps me.
PLEASE understand what my program is doing and decide if it is suits you or not.

I found "cpulimit" (can be installed from software center - at least in Ubuntu 15.10) which slows down a particular thread.
No, "nice" does not do the work, because "nice" just gives priorities and here we want that CPUs do not do "anything".

I wrote a small python script which
- checks if screen lock OR screensaver became active, if yes, it limits that thread with "cpulimit"
- checks if screen lock OR screensaver became inactive, if yes, ir removes all limitation

Again, it slows down compiz so violently as possible.
With my system the keyboard lock (Alt-Ctrl-L) fades out for 5-10 secs...
when I enter my password dots has 1 sec lag...

Screensaver part is added to eliminate this lock-screen delay.
Under "normal use" screensaver deactivates earlier, so compiz became much more responsive.

If your programs use compiz during screen lock, it is VERY LIKELY that this script will slow down or somehow affect those programs as well, so use it wisely!

For the script running you have to install python-dbus if you did not do it so far:
sudo apt-get install python-dbus

The python script itself:

#!/usr/bin/env python
import gobject
import dbus
import os
from dbus.mainloop.glib import DBusGMainLoop

def lock_and_screensaver_filter(bus, message):
  EventMember =message.get_member()
  if EventMember == "EventEmitted":
    args = message.get_args_list()
    if args[0] == "desktop-lock":
      os.system("cpulimit -b -P /usr/bin/compiz -l 1")
    elif args[0] == "desktop-unlock":
      os.system("pkill cpulimit")
  elif EventMember == "ActiveChanged":
    args = message.get_args_list()
    if args[0] == True:
      os.system("cpulimit -b -P /usr/bin/compiz -l 1")
      os.system("pkill cpulimit")

bus = dbus.SessionBus()
mainloop = gobject.MainLoop()

John (john-levin) wrote :
Download full text (3.5 KiB)

The PAM user authenticator in the unity lockscreen busy waits because of a bug in std::future in libstdc++6.

The libstdc++ bug is decribed here, including a patch for fixing it:
(GCC Bugzilla – Bug 68921 [5/6 Regression] std::future::wait() makes invalid futex calls and spins)

strace on compiz while the lockscreen is active shows the following system call being repeated:
futex(0xb32f7a9c, FUTEX_WAIT, -2147483648, {2948397076, 2}) = -1 EINVAL (Invalid argument)

Here is a backtrace of the affected thread in compiz when it is in that syscall:
#0 0xb7795be8 in __kernel_vsyscall ()
#1 0xb74485a7 in syscall () at ../sysdeps/unix/sysv/linux/i386/syscall.S:29
#2 0xb75d8336 in std::__atomic_futex_unsigned_base::_M_futex_wait_until (this=0xb32f7a9c, __addr=0xb32f7a9c, __val=2147483648, __has_timeout=false, __s=...,
    __ns=...) at ../../../../../src/libstdc++-v3/src/c++11/
#3 0xafa5c04f in std::__atomic_futex_unsigned<2147483648u>::_M_load_and_test_until (__ns=..., __s=..., __has_timeout=<optimized out>, __mo=<optimized out>,
    __equal=<optimized out>, __operand=<optimized out>, __assumed=<optimized out>, this=<optimized out>) at /usr/include/c++/5/bits/atomic_futex.h:104
#4 std::__atomic_futex_unsigned<2147483648u>::_M_load_and_test (__mo=<optimized out>, __equal=<optimized out>, __operand=<optimized out>,
    __assumed=<optimized out>, this=<optimized out>) at /usr/include/c++/5/bits/atomic_futex.h:122
#5 std::__atomic_futex_unsigned<2147483648u>::_M_load_when_equal (__mo=std::memory_order_acquire, __val=1, this=0xb32f7a9c)
    at /usr/include/c++/5/bits/atomic_futex.h:162
#6 std::__future_base::_State_baseV2::wait (this=0xb32f7a94) at /usr/include/c++/5/future:322
#7 std::__basic_future<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::_M_get_result (this=<synthetic pointer>)
    at /usr/include/c++/5/future:681
#8 std::future<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::get (this=<synthetic pointer>)
    at /usr/include/c++/5/future:760
#9 unity::lockscreen::UserAuthenticatorPam::ConversationFunction (num_msg=1, msg=0xa7dba0a8, resp=0xa7dba0a4, appdata_ptr=0xa3c4174)
    at /build/unity-G7ZJ7L/unity-7.3.2+15.10.20151016/lockscreen/UserAuthenticatorPam.cpp:151
#10 0xae996243 in pam_vprompt () from /lib/i386-linux-gnu/
#11 0xae99640c in pam_prompt () from /lib/i386-linux-gnu/
#12 0xabd24a7e in ?? () from /lib/i386-linux-gnu/security/
#13 0xabd22093 in pam_sm_authenticate () from /lib/i386-linux-gnu/security/
#14 0xae991450 in ?? () from /lib/i386-linux-gnu/
#15 0xae990c7a in pam_authenticate () from /lib/i386-linux-gnu/
#16 0xafa5a992 in unity::lockscreen::UserAuthenticatorPam::<lambda(GTask*, gpointer, gpointer, GCancellable*)>::operator() (__closure=0x0, task=0x96c56d0,
    data=0xa3c4174) at /build/unity-G7ZJ7L/unity-7.3.2+15.10.20151016/lockscreen/UserAuthenticatorPam.cpp:55
#17 unity::lockscreen::UserAuthenticatorPam::<lambda(GTask*, gpointer, gpointer, GCancellable*)>::_FUN(GTask *, gpointer, gpointer, GCancellable *) ()
    at /...


Matthew Carpenter (matt-eisgr) wrote :

I'm running into this problem on Ubuntu 15.10 as well. I originally didn't realize it was the *locked* session that caused difficulties. I just noticed that when my kids logged on, after a half hour the system would power down. This is because compiz at 100%+ CPU heated up the CPU to 114C within that time period. I was tracking lm-sensors output, logs, and finally top, all at the same time, through SSH sessions from another system. I just now determined that it was compiz, only when locked. (btw, media servers with RAID-5 arrays is not the machine you want to hard-power-down repeatedly).

Any hopes for a fix?

Matthew Carpenter (matt-eisgr) wrote :

Or rather, any hopes to get this libc bug mainlined for 15.10?
or an *actual* workaround (aside from only using KDE)?
This bug is a *big* deal

LGB [Gábor Lénárt] (lgb) wrote :

I have this bug (also as bug 1508219 which is now marked as duplication of this report) on three different machines, each of them were verified via ssh, that indeed, compiz uses 100% CPU when screen is locked. All of them is up-to-date 15.10, one notebook (intel), one desktop (also integrated intel stuff onboard), and one another desktop but with AMD/APU configuration. I also see wild memory leaking like happenings on one of the machines at least (others are not used with long enough uptime to be able to notice, maybe?), eg, according to top, memory usage of compiz starts from something like 4% but it's 14% after three days of being locked, it was also 41% after a week or so once ... And yes, CPU is always at 100% at the momemnt I lock the screen even without power saving of monitor, etc. On all of those machines. Quite annoying, because of fan noise, and especially on the notebook, it's not so great for the battery to have long on battery usage, as you can imagine :(

Andrea Olivo (andryandrew) wrote :

I also experience this bug, on nVidia (GT220) and 32-bit Ubuntu Wily.

Waiting for gcc 5.4 that will fix the regression, I hope?

David Aceituno (davidace) wrote :

I have the same problem on Ubuntu 16.04 LTS xenial, with a Thinkpad T430s.

Ihor Sviziev (ihor.sviziev) wrote :

I have the same issue on Ubuntu 16.04 LTS on Dell Latitude E7440

NoBugs! (luke32j) wrote :

I'm seeing this with 14.04 and Firefox "Web Content" high cpu use on a:
Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
Linux 4.4.0-57-generic

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.