Ubuntu
compiz package

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

Bug #1322751 reported by Benjamin Xiao on 2014-05-23

162

This bug affects 34 people

Affects		Status	Importance	Assigned to	Milestone
	Compiz	New	Undecided	Unassigned
	compiz (Ubuntu)	Confirmed	Undecided	Unassigned

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 https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/969860, 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
.tmp.unity.support.test.0:

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
GraphicsCard:
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
ProcEnviron:
LANGUAGE=en_US
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
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)
dmi.bios.date: 03/26/2014
dmi.bios.vendor: LENOVO
dmi.bios.version: GRET36WW (1.13 )
dmi.board.asset.tag: Not Available
dmi.board.name: 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:
dmi.product.name: 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.errors:

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

Tags:

Revision history for this message

Benjamin Xiao (ben-r-xiao) wrote on 2014-05-23:

BootDmesg.txt Edit (68.8 KiB, text/plain; charset="utf-8")
BootLog.txt Edit (5.2 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (11.8 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (9.2 KiB, text/plain; charset="utf-8")
DpkgLog.txt Edit (1.7 MiB, text/plain; charset="utf-8")
GconfCompiz.txt Edit (45.6 KiB, text/plain; charset="utf-8")
LightdmDisplayLog.txt Edit (2.2 KiB, text/plain; charset="utf-8")
LightdmGreeterLog.txt Edit (22.2 KiB, text/plain; charset="utf-8")
LightdmGreeterLogOld.txt Edit (16.1 KiB, text/plain; charset="utf-8")
LightdmLog.txt Edit (4.8 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (8.6 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (898 bytes, text/plain; charset="utf-8")
MonitorsUser.xml.txt Edit (3.2 KiB, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (4.0 KiB, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (2.3 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (4.4 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (162.9 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (353.0 KiB, text/plain; charset="utf-8")
UnitySupportTest.txt Edit (610 bytes, text/plain; charset="utf-8")
XorgLog.txt Edit (31.6 KiB, text/plain; charset="utf-8")
XorgLogOld.txt Edit (24.6 KiB, text/plain; charset="utf-8")
Xrandr.txt Edit (12.2 KiB, text/plain; charset="utf-8")
xdpyinfo.txt Edit (6.8 KiB, text/plain; charset="utf-8")
xserver.devices.txt Edit (514 bytes, text/plain; charset="utf-8")

Revision history for this message

Benjamin Xiao (ben-r-xiao) wrote on 2014-05-24:

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.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2014-07-18:

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

Changed in compiz (Ubuntu):
status:	New → Confirmed

Revision history for this message

Maksim Lin (maks-j) wrote on 2014-12-02:

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

Revision history for this message

Benjamin Xiao (ben-r-xiao) wrote on 2015-01-20:

Still seeing this behavior on 15.04 alpha

Revision history for this message

Philipp (c-ubuntu-f) wrote on 2015-03-18:

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.

Revision history for this message

Philipp (c-ubuntu-f) wrote on 2015-07-01:

The problem still occurs in 15.04 with kernel 3.19.0-21 and Compiz :0.9.12.1+15.04.20150410.1-0ubuntu1.

Revision history for this message

fcole90 (fcole90) wrote on 2015-10-03:

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

Revision history for this message

Michiel (michielhaisma) wrote on 2015-10-18:

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

Revision history for this message

V-Mark (vertesmark) wrote on 2015-11-10:

#10

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 https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/969860
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

Revision history for this message

V-Mark (vertesmark) wrote on 2015-11-10:

#11

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.

Revision history for this message

V-Mark (vertesmark) wrote on 2015-11-11:

#12

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")
    else:
      os.system("pkill cpulimit")

DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
bus.add_match_string("type='signal',interface='com.ubuntu.Upstart0_6'")
bus.add_match_string("type='signal',interface='org.gnome.ScreenSaver'")
bus.add_message_filter(lock_and_screensaver_filter)
mainloop = gobject.MainLoop()
mainloop.run()

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.

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

Revision history for this message

John (john-levin) wrote on 2015-12-29:

#13

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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921
(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/futex.cc:55
#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/libpam.so.0
#11 0xae99640c in pam_prompt () from /lib/i386-linux-gnu/libpam.so.0
#12 0xabd24a7e in ?? () from /lib/i386-linux-gnu/security/pam_unix.so
#13 0xabd22093 in pam_sm_authenticate () from /lib/i386-linux-gnu/security/pam_unix.so
#14 0xae991450 in ?? () from /lib/i386-linux-gnu/libpam.so.0
#15 0xae990c7a in pam_authenticate () from /lib/i386-linux-gnu/libpam.so.0
#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 /...

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

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/futex.cc:55
#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/libpam.so.0
#11 0xae99640c in pam_prompt () from /lib/i386-linux-gnu/libpam.so.0
#12 0xabd24a7e in ?? () from /lib/i386-linux-gnu/security/pam_unix.so
#13 0xabd22093 in pam_sm_authenticate () from /lib/i386-linux-gnu/security/pam_unix.so
#14 0xae991450 in ?? () from /lib/i386-linux-gnu/libpam.so.0
#15 0xae990c7a in pam_authenticate () from /lib/i386-linux-gnu/libpam.so.0
#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 /build/unity-G7ZJ7L/unity-7.3.2+15.10.20151016/lockscreen/UserAuthenticatorPam.cpp:62
#18 0xb461ec98 in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
#19 0xb708c864 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#20 0xb708be0a in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#21 0xb6ff51aa in start_thread (arg=0xa7dbab40) at pthread_create.c:333
#22 0xb744cfde in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122

Revision history for this message

Matthew Carpenter (matt-eisgr) wrote on 2016-01-22:

#14

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?

Revision history for this message

Matthew Carpenter (matt-eisgr) wrote on 2016-01-22:

#15

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

Revision history for this message

LGB [Gábor Lénárt] (lgb) wrote on 2016-01-25:

#16

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 :(

Revision history for this message

Andrea Olivo (andryandrew) wrote on 2016-02-16:

#17

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?

Revision history for this message

David Aceituno (davidace) wrote on 2016-05-18:

#18

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

Revision history for this message

Ihor Sviziev (ihor.sviziev) wrote on 2016-07-13:

#19

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

Revision history for this message

NoBugs! (luke32j) wrote on 2016-12-29:

#20

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

Report a bug

This report contains Public information

Everyone can see this information.

Duplicates of this bug

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

gcc-bugzilla #68921 Edit

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

Ubuntucompiz package

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

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
compiz package