fglrx uses 100% CPU when screen turns off (spinning in glXWaitVideoSyncSGI or glXSwapBuffers)

Bug #969860 reported by Jean-Baptiste Lallement
666
This bug affects 134 people
Affects Status Importance Assigned to Milestone
Compiz
Invalid
High
Unassigned
0.9.8
Invalid
High
Unassigned
Compiz Core
Invalid
High
Unassigned
The Ubuntu Power Consumption Project
Fix Released
Undecided
Unassigned
fglrx
Confirmed
Medium
compiz (Ubuntu)
Invalid
High
Canonical Desktop Experience Team
fglrx-installer (Ubuntu)
Fix Released
Critical
Unassigned
fglrx-installer-updates (Ubuntu)
Fix Released
Critical
Unassigned
gnome-shell (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

WORKAROUND (1):
1. Open Catalyst Control Center.
2. Go to 3D > More Settings.
3. Set "Wait for vertical refresh" to "On, unless application specifies".
And if that doesn't work, then also do:
4. Run "ccsm"
5. In Workarounds, enable "Force full screen redraw (buffer swap) on repaint".

WORKAROUND (2):
1. Run ccsm (from package compizconfig-settings-manager)
2. In OpenGL > Sync To VBlank = OFF

TEST CASE:
1. Monitor compiz CPU usage (from /proc/<pid of compiz>/stat or top in batch mode)
2. In "brightness and lock" settings set "Turn screen off when inactive" to 1 minute
3. Wait until screen turns off
4. Move mouse or press a key to turn screen back on
5. Check the CPU usage from the monitor

ACTUAL RESULT:
When screen turns off compiz goes to 100%
When the screen turns back on, cpu usage drops immediately to a normal value
The graph attached shows %CPU of compiz with a sample per second. The graph has been captured on a system with a Radeon HD5770 and fglrx if that matter

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: compiz 1:0.9.7.2-0ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
Uname: Linux 3.2.0-21-generic x86_64
NonfreeKernelModules: fglrx
.tmp.unity.support.test.0:

ApportVersion: 2.0-0ubuntu1
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: compiz
Date: Sat Mar 31 10:17:48 2012
DistUpgraded: 2012-02-01 00:15:24,616 DEBUG enabling apt cron job
DistroCodename: precise
DistroVariant: ubuntu
MachineType: Gigabyte Technology Co., Ltd. GA-890GPA-UD3H
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-21-generic root=UUID=cf89ba34-108b-404d-9804-32d54a1df2ea ro quiet splash vt.handoff=7
SourcePackage: compiz
UpgradeStatus: Upgraded to precise on 2012-01-31 (59 days ago)
dmi.bios.date: 07/23/2010
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: FD
dmi.board.name: GA-890GPA-UD3H
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrFD:bd07/23/2010:svnGigabyteTechnologyCo.,Ltd.:pnGA-890GPA-UD3H:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-890GPA-UD3H:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-890GPA-UD3H
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
version.compiz: compiz 1:0.9.7.2-0ubuntu4
version.fglrx-installer: fglrx-installer N/A
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
Changed in compiz (Ubuntu):
importance: Undecided → High
assignee: nobody → Canonical Desktop Experience Team (canonical-dx-team)
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I can't reproduce this with intel graphics in 12.04.

jibel, could you please try ssh'ing into the machine when this happens and getting a few stack snapshots of the busy compiz process using gdb?

This bug might be related to the buggy implementation of wait-for-vsync in the fglrx driver. So please also try this as a workaround:

1. Open Catalyst Control Center.
2. Go to 3D > More Settings.
3. Set "Wait for vertical refresh" to "On, unless application specifies".

And if that doesn't work, then also do:

4. Run "ccsm"
5. In Workarounds, enable "Force full screen redraw (buffer swap) on repaint".

Changed in compiz (Ubuntu):
status: New → Incomplete
summary: - compiz uses 100% CPU when screen turns off
+ [fglrx] compiz uses 100% CPU when screen turns off
Changed in compiz-core:
status: New → Incomplete
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote : Re: [fglrx] compiz uses 100% CPU when screen turns off

- Setting "Wait for vertical refresh" to "On, unless application specifies" doesn't work.
- But setting enable "Force full screen redraw (buffer swap) on repaint" in CCSM does work.

strace shows that compiz loops on
ioctl(12, 0xc00c645c, 0x7fff3791e1f0) = 0

where 12 is /dev/ati/card0

Daniel, I'd be happy to provide stack snapshots with gdb if you'd tell me how. Thanks for your help.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

jibel, here's a tool that will output the stack info. You can run it as:
    sh ./dstack compiz > compizstack.txt

And then please attach compizstack.txt to this bug.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Actually, while compiz is spinning at 100% CPU please run this command several times:
    sh ./dstack compiz >> compizstack.txt

Revision history for this message
Filipe Manco (fmanco) wrote :

I'm affected by this bug too.

Enabling "Force full screen redraw (buffer swap) on repaint" doesn't work for me.
This workaround just delays the problem, i.e. the compiz takes more time (about 30 minutes) to use 100% of cpu.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

All - Please provide the stack info as requested in comments #4 and #5. You will need to ssh into your machine while the screen is off to do so.

Revision history for this message
drumour (drumour) wrote :

I appear to have this happening on two near identical 12.04 beta 2 ati systems. Have attached stack info as requested above

Revision history for this message
Aurélien Leblond (blablack) wrote :

I am having the same problem with an HP Envy 17 (Mobility Radeon HD 5800 Series) with FGLRX (I can't reproduce it with the open source driver).

I attached the stack output.

Revision history for this message
Matt Fischer (mfisch) wrote :

I can always tell when my screen is blanked because my CPU fan is roaring. I on an HP elitebook with Radeon HD 6470M graphics and am running the fglrx driver.

I found that it takes about a minute for the CPU to start spiking after the screen blanks. From running top, compiz goes from 0 (for about the first 20 seconds) to 30 to 100.

I ran your script in a loop every 5 seconds, there are approx 26 runs in that file The last stack in there may show it starting to wake-up as I bumped the mouse during the last trace.

If I can gather more info, please let me know.

Revision history for this message
Filipe Manco (fmanco) wrote :

The stack output is attached as requested.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: [fglrx] compiz uses 100% CPU when screen turns off (spinning in glXWaitVideoSyncSGI or glXSwapBuffers)

Thanks all. Your stack outputs confirm everyone has the same problem.

summary: - [fglrx] compiz uses 100% CPU when screen turns off
+ [fglrx] compiz uses 100% CPU when screen turns off (spinning in
+ glXWaitVideoSyncSGI or glXSwapBuffers)
Changed in compiz-core:
importance: Undecided → High
status: Incomplete → Triaged
Changed in compiz (Ubuntu):
status: Incomplete → Triaged
description: updated
Changed in compiz-core:
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in compiz-core:
milestone: none → 0.9.7.8
Changed in ubuntu-power-consumption:
status: New → Confirmed
Revision history for this message
Avery (docaltmed) wrote :

This bug also effects me. I'm on Ubuntu 11.10 with Radeon 6600M.

Revision history for this message
Lem (lem-jjr) wrote :

Same bug here, HP dm1-3010au (AMD E-350), Ubuntu 12.04, Catalyst from Ubuntu repository.

Revision history for this message
Mikolaj (mikolaj-babiak) wrote :

Same bug (AMD A8-3510MX). Workaround from first post worked for me.

Revision history for this message
Evren Yurtesen (eyurtese-g) wrote :

Same problem HP dm1z-4100 (amd e-450)
Setting "Force full screen redraw (buffer swap) on repaint" seems to improve performance overall, compiz normally uses 60-80% cpu when moving a window (crazy right?) and when set "Force full screen redraw (buffer swap) on repaint" it uses only ~30%.

Also the cpu usage is near zero % when the screen is off with the "Force full screen redraw (buffer swap) on repaint" option.

Revision history for this message
Jose Padilla (sargepl) wrote :

This bug alse affects me (Ubuntu 12.04 with last catalyst driver from Ubuntu Packages on a Zotac AD02, AMD Fusion E-350). I'm testing the first workaround.

Revision history for this message
Jose Padilla (sargepl) wrote :

The option "Force full screen redraw (buffer swap) on repaint" also reduces the CPU usage with a NVIDIA Go 7700 (last driver version from Ubuntu Package) on an Asus G1 laptop (Ubuntu 12.04).

Revision history for this message
Jose Padilla (sargepl) wrote :

The workaround seems to work. Thank you.

Revision history for this message
Gert Kok (yawarakaimono) wrote :

Workaround (Catalyst: 'wait...' + CCSM: 'force...' ) is OK
ATI Radeon HD 5670
dual screen mode

Revision history for this message
Sascha Jazbec (jazbec) wrote :

deactivating all vsyncing, both in ccsm + in amd catalyst makes compiz snappier and less cpu intense for me ( hd 4650 mobility ).

The windows are tearing slightly when moving, but that is not a serious topic when it comes to the overall desktop expierence. Unity already makes the cpu more hot, so every fix to lower that pressure is a welcome, at least to me.
I also lowered the mouse polling intervall from 40 to 20 in ccsm and checked the "fix fglrx" under "workarounds" in ccsm.

Unity MT-Grab Handles I have turned off. These make only sense if we are on a touchscreen.

I also uninstalled the liboverlayscrollbar packages - first because I dislike Ubuntus strange new scrollbars and second I found that without them the scrolling is more fluid.

and last :

If all the tweaking and tinkering with compiz/ unity3d is too much for you but you still want to use unity : run the "2d" session. This has all the Dash and HUD stuff, but all compiz and cpu hogging is solved instantly because it is not used, making your pc run very much quicker.

Revision history for this message
Aurélien Leblond (blablack) wrote :

Workaround (Catalyst: 'wait...' + CCSM: 'force...' ) doesn't work for me.
ATI Radeon HD 5700

Revision history for this message
Кузнецов Андрей (andrew-kuznecov) wrote :

Workaround doesn't work for me.
ATI Radeon HD 6870

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

If the workaround doesn't work for you, please follow the instructions in comments #4 and #5.

Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
importance: Undecided → High
status: New → Triaged
Revision history for this message
odror (ozdror) wrote :

I have the same issue with catalyst version 12.4 (from the web site) and HD 6850. The workaround did not work for me at all. I have the same issue in Unity 3d and gnome 3. No issues with KDE (with compiz).

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I thought this was a compiz-only issue. Does anyone else have the bug with Gnome Shell?

Changed in compiz:
milestone: none → 0.9.8.0
no longer affects: compiz-core/0.9.8
Changed in compiz-core:
milestone: 0.9.8.0 → 0.9.7.10
no longer affects: compiz-core/0.9.7
Revision history for this message
Chris Merrett (chrisfu) wrote :

Well, for the time being I've switched from Unity to Unity 2D (metacity) and I'm no longer having the issue at all. Whenever I've seen the problem compiz has been the only process hitting 100% when the screen is off. When the machine is left in this state for some time I sometimes end up finding that the machine has hard-locked.

I've noticed that on occasion compiz hits 60-80% with the screen on too when not much is happening.

Catalyst 12.4 (fglrx-updates) and AMD Radeon HD 5830.

Revision history for this message
Forage (forage) wrote :

I can confirm that this issue occurs with gnome-shell as well. It has been bugging me for a while now since it already started to occur in Ubuntu 11.10, again with gnome-shell.

OS: Ubuntu 12.04 (x64)
Video card: ATI HD6950
Drivers: proprietary AMD CCC 12.4 (fglrx 8.961)

Revision history for this message
capiporra (jcaceres77) wrote :

Thi is my stack with ubuntu 12.04+unity3d+Catalist 12.04 (I get the same problem with opensource drivers)

Compiz raise to 100% in idle state.

Revision history for this message
capiporra (jcaceres77) wrote :

more info missed in #29 (sorry)

Device: Dell Inspiron 5010
GPU: ATI Mobility Radeon HD 5650
Process: compiz 1:0.9.7.8-0ubuntu1

With same config that out the box , no tweaks, mods or whatever modification

Revision history for this message
SlugiusRex (slugiusrex) wrote :

The symptoms here seems kinda similar to Bug #969359. Was the fix to this related to the gnome-settings-daemon?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

SlugiusRex, no this bug is not related to gnome-settings-daemon. Only the fglrx driver and compiz.

Revision history for this message
Pēteris Caune (cuu508) wrote :

Same problem with gnome-shell, attaching stack traces.

Ubuntu 12.04
Radeon 6870
Version of fglrx-updates is 2:8.960-0ubuntu1

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Marked as affecting gnome-shell, as reported by multiple people. Also affects fglrx, obviously.

summary: - [fglrx] compiz uses 100% CPU when screen turns off (spinning in
+ fglrx uses 100% CPU when screen turns off (spinning in
glXWaitVideoSyncSGI or glXSwapBuffers)
Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Changed in fglrx-installer (Ubuntu):
status: New → Confirmed
Changed in fglrx-installer-updates (Ubuntu):
status: New → Confirmed
Revision history for this message
Forage (forage) wrote :

The set "Wait for vertical refresh" to "On, unless application specifies" workaround does not fix the issue when running gnome-shell. Compiz is not being used when using gnome-shell. Therefore I expect there will be no point in installing ccsm to try the alternative workaround. Is this assumption correct?

If yes, would there be anything else worth trying?

Revision history for this message
Forage (forage) wrote :

Also, updating the driver to AMD CCC 12.6 beta (fglrx 8.980) does not solve the issue either.

Revision history for this message
Forage (forage) wrote :

I reported the issue "upstream" at http://ati.cchtml.com/show_bug.cgi?id=535

Revision history for this message
capiporra (jcaceres77) wrote :

In Ubuntu 11.10 with catalyst 11.8 or fglrx this bug isn't present. At least I can't replicate it

Revision history for this message
Filipe Manco (fmanco) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I figured this was driver behaviour unique to fglrx so it's not surprising it happens on Windows too. However we might yet be able to work around it in Compiz.

Revision history for this message
cgrushko (carmi-grushko) wrote :

Affects me too, both workarounds do not solve problem.
Running Ubuntu 12.04 with ATI 5850HD.
Attached compiz stack traces.

Revision history for this message
Derek Chen-Becker (dchenbecker) wrote :

Here's my stack trace. dstack kept hanging, so I just ran gdb manually. This appears to be the same bug, but the workarounds don't help. This is a:

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Manhattan [Mobility Radeon HD 5430 Series]

And the ioctl that loops is

ioctl(13, 0xc00c645c, 0x7fff5a9fde00) = 0

Where 13 is /dev/ati/card0. fglrx is 2:8.960-0ubuntu1, x86_64, Ubuntu 12.04

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Weirdly, this bug does not happen if I turn the screen off using:
    xset dpms force off
But it does still happen if I let the gnome screensaver kick in and turn the monitor off.

Does that mean it's a problem specifically with ACPI? It doesn't happen with DPMS.

Revision history for this message
Arian Bär (arian-baer) wrote :

For me changing from the gnome-screensaver to the xscreensaver worked.
I still have around 7% of CPU usage from compiz while the screen is locked, which in my opinion is still a lot for displaying nothing, but at least it consumes less battery on my laptop.

I am running Ubuntu 12.04 on a HP EliteBook 8470p with AMD 7570M graphics.

Revision history for this message
capiporra (jcaceres77) wrote :

I've disabled screensavers and I can replicate the issue only closing the lid of my laptop (configured to "do nothing" in power settings)

*My stacktrace is posted above

ACPI problem has sense. ¿maybe passing acpi=off at boot options does the trick?

I can't do it myself at this moment. I'm out of my house for a few days.

my2cents.

Revision history for this message
Gregor Riepl (onitake) wrote :

Followed the advice of #21 and disabled vsync in ccsm. It's already off in ccc.

This helped against the spin, and I experience no noticable tearing. The other workarounds didn't help.

Running on AMD E-450, Ubuntu 12.04, Unity, fglrx-updates 8.860 (12.4)

Revision history for this message
George (george-labuschagne-gmail) wrote :

For the workaround to work I had to run catalyst control centre as administrator and disable tearfree. I forgot that I had that enabled and made all the changes in the workaround to no avail. As soon as I disabled tearfree and set vsync as per the workaround in admin mode it worked :)

Revision history for this message
capiporra (jcaceres77) wrote :

OK, thanks to George's tip I finally solved the problem just disabling "tear-free" in catalyst center (admin mode) and the configuration proposed in the workaround:

(obviously with the proprietary ATI fglrx)

1. Open Catalyst Control Center (admin mode).
2. Display Options -> Tear Free-> disabled
3. Go to 3D > More Settings.
4. Set "Wait for vertical refresh" to "On, unless application specifies".

With tear-free enabled, I always get compiz at 100% inmediatly when close the lid of my laptop or 30 minutes after (aprox).

I've tried to replicate the problem many many times with tear-free disabled but is imposible, now is working flawless. My laptop and compiz process enjoys a cool and quiet idle mode indefinitely.

I suppose that "tear-free" is enabled by default in the opensource driver, this would explain why this occurs with this driver too.

___________________________________________
Ubuntu 12.04
Catalyst Control Center: 12.4
Driver package: 8.96.7-120312A-135598c-ATI
2D Driver: 8.96.4

Revision history for this message
Forage (forage) wrote :

I'm a bit surprised to hear that disabling Tear Free solves the issue. I've tried that in the past, in combination with vsync, and today again, but to no avail.

I'm using GNOME Shell, are you perhaps using Unity?

Revision history for this message
George (george-labuschagne-gmail) wrote :

Yes I am using Unity. Not sure if you disabled "Tear Free" in normal or admin mode? I had to disable it in admin mode and set the vsync setting to "On, unless application specifies" also in admin mode for this workaround to take effect.

Revision history for this message
Forage (forage) wrote :

I'm always using admin mode when making changes in CCC. I gave it another go, followed by a reboot as well, but the issue remains.

Revision history for this message
st2000 (stuart-xnet) wrote :

Regarding high CPU usage when screen turns off.

I might have had a real casualty of this bug. An 18 day old HP Pavilion g6 failed after being left unattended for about 1 hour while running Ubuntu. The laptop was on a hard smooth surface in an air conditioned environment. It was found fan running, warm to the touch and screen completely black. Nothing could be done to exit this state. The failed laptop was returned to a Compaq facility where I expect they are intent on finding the root cause of failure (I do not believe this was a repair facility).

The replacement HP Pavilion g6 (a slightly different model) is also warm to the touch when the screen turns off. Leading me to this bug report. Conclusions, the problems stated here may be the secondary cause of the first laptop's failure. The primary cause of course would be the laptop's inability to sustain high CPU usage.

(Some) information from the 2nd laptop:
lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Device 9903
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Thames XT/GL [Radeon HD 7600M Series]
uname -a
Linux frodo 3.2.0-27-generic-pae #43-Ubuntu SMP Fri Jul 6 15:06:05 UTC 2012 i686 athlon i386 GNU/Linux

Revision history for this message
Ari (ari-lp) wrote :

Confirmed. Workarounds don't work. I would love to supply the stack info as requested in posts #4 and #5. But when I enter the command I get the following error message:

~$ sudo sh ./dstack compiz >> compizstack.txt
sh: 0: Can't open ./dstack

Also, how can I enter the command when the problem disappears as soon as I unlock my machine?

Revision history for this message
Ari (ari-lp) wrote :

Here's some additional adata on my machine:

lspci | grep VGA
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Madison [Radeon HD 5000M Series]

(Mobility Radeon HD 5650 on Acer 3820TG)

uname -a
Linux AcerUBN 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Catalyst™-Version 12.6
Driver Version 8.98-120611a-141410C-ATI
2d Driver 8.98.2
Catalyst control center version 2.15
RandR version 1.3

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

@knowhow91:

> ~$ sudo sh ./dstack compiz >> compizstack.txt
> sh: 0: Can't open ./dstack

About the "Can't open ./dstack" error: you need to download the script first. It's attached on comment #4.

> Also, how can I enter the command when the problem disappears as soon as I unlock my machine?

Try this:

  sudo sh -c "sleep 5; sh $HOME/dstack compiz" >> compizstack.txt

Launch the command, immediately lock the screen and wait for 10 seconds, then unlock the screen. This will dump the stack in the middle of the screen lock.

Revision history for this message
Evren Yurtesen (eyurtese-g) wrote :

I just installed Ubuntu 12.04 to a desktop machine with Radeon HD 5870 and compiz is using 100% when the screen is off. I didnt try any of the workarounds on this machine. There are so many workarounds mentioned and half of them seem to work only for half of the people. I dont know where to start... Why compiz can not stop itself when the screen is off (since there is nothing to show?) ...strange...

Revision history for this message
Ari (ari-lp) wrote :

I am sorry, I'll have to revoke my statement. After restarting the system everything works fine again thanks to the workarounds posted in the OP. Thank you for saving my notebook from an untimely heat death.

Revision history for this message
Rafael García (rgo) wrote :

I updated my kernel to 3.4.6 , disabled all the workarounds and know it's working right (fixed).

I used the last quantal(12.10) kernel packages (Linux envy 3.4.6-030406-generic #201207191609 SMP Thu Jul 19 20:11:13 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux version) in my ubuntu 12.04

Revision history for this message
Rafael García (rgo) wrote :

Forget my previous comment, it's failing again :(

Yesterday it was working but today, after shutdown at night, cpu up to 100% when the screen turns off.

Revision history for this message
chkneater (chkneater) wrote :

I just wanted to add that I had the same problem for a while so I started checking the temp every 10 mins or so and it was solid at 62-65C with a full load. I deduced the only time I had issues with it overheating was when the screensaver was on. I turned it off and set the display to turn off after 30 mins. and it hasn't overheated since. That may help as I believe the fglrx restricted extras are the suspect.

Revision history for this message
Omer Akram (om26er) wrote :

@Daniel, what do you think this bug needs fixing? If its fglrx we could ask Canonical-Xorg team to talk to AMD maybe?

no longer affects: compiz-core
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Omer,

How and what needs fixing depends on the outcome of more testing on fglrx that I have not had time to do yet.

It really depends if the spin is always below glXWaitVideoSyncSGI/glXSwapBuffers, or if the functions are returning back to compiz on each iteration (too quickly).

If anyone else has time to look into this bug then please do.

Revision history for this message
capiporra (jcaceres77) wrote :

Sorry but I forgot some info in the workaround proposed in #48

I disabled "Sync to VBlank"in ccsm->OpenGL.

Since 1 August no more compiz overloaded in standby mode

If I enable Sync to VBlank, when I close the lid of my notebook, compiz raise to 100% inmediately, with Sync to VBlank disabled never happens (until today at least)

description: updated
Revision history for this message
capiporra (jcaceres77) wrote :

Well, this is a little bit embarrasing.

The workaroung porposed in #48 have another error, sorry.

I prefer to detail it again.

This is the only workaround that works for me:

### ATI Privative ########################
_________________________________________________________________________________

ccsm->OpenGL->Sync to VBlank [disabled]

1. Open Catalyst Control Center (admin mode).
2. Display Options -> Tear Free-> [disabled]
3. Go to 3D > More Settings.
4. Set "Wait for vertical refresh" -> "Off unless aplication specifies".
_________________________________________________________________________________

With "Wait for vertical refresh"-> "On, unless application specifies", I've problems with compiz with ot without "Sync to VBlank" enabled.

Enabling "cssm->workarounds->Force full screen redraws (buffer swap) on repaint" doesn't solve the problem in any workaround while vsync is enabled in cssm or catalyst control center. But disabling vsync completely and enabling "Force full screen redraws (buffer swap) on repaint" seems that reduce the tearing a little bit. Anyway, obviously since I don't have vsync I'm suffering of tearing.

### Radeon OpenSource ########################

In the other hand, with the radeon opensource driver, only disabling "ccsm->OpenGL->Sync to VBlank" (keeping "buffer swap" dissabled) solves the problem and don't suffer tearing (but the GPU temp is clearly hottest comparing with privative). I'm testing since two days without problems. In a few days will report if I had more problems or I can replicate the problem with compiz

Resuming, only the [WORKAROUND 2] solves the problem (in my case)

As curiosity, In Ubuntu 11.10, when I install the privative driver, I always need to disable "ccsm->OpenGL->Sync to VBlank" to reduce tearing or some type of ¿shuttering? when moving windows quickly, and enable "Tear free" in the catalyst Control Center.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

capiporra, please see bug 880707 about Ubuntu 11.10.

Changed in compiz:
milestone: 0.9.8.0 → 0.9.8.1
Revision history for this message
MVNregress (pukakk) wrote :

compiz 0.9.8.1 doesn't solve the problem.

Changed in compiz:
milestone: 0.9.8.2 → 0.9.8.4
Revision history for this message
Ari (ari-lp) wrote :

Just a small heads-up:

Activating "Force full screen redraw (buffer swap) on repaint" caused a significant increase in CPU load with regular usage on my system. That's why I had to go back to deactivating the automatic screen switch entirely.

In the course of doing so I discovered another bug in that the automatic screen lock does not work as long as the display isn't turned off. Has anyone else experienced something similar here?

Changed in compiz:
milestone: 0.9.8.4 → 0.9.9.0
assignee: Daniel van Vugt (vanvugt) → nobody
Revision history for this message
capiporra (jcaceres77) wrote :

Is this bug solved in Ubuntu 12.10 ?? I cant't test beta2 by myself right now, sorry.

@DanielVanVugt, if you need some test, logs or alternative workarounds, I can help (if you want, of course)

Revision history for this message
odror (ozdror) wrote :

no it was not with beta 1.

Revision history for this message
Jelu (ghotomcity) wrote :

still affects me on 12.10 Gnome Remix

Revision history for this message
Alex Tudorache (alextudorache) wrote :

I had the same problem for a while now, until recently I found a solution which I'm going to share with you. I know it's not the ideal approach, but I hope it will be useful for you guys until someone fixes the issue.

Investigating I found that installing Caffeine in my Ubuntu 12.04.1 and checking the "Disable Screensaver" option fixed the problem for me. I also checked the option "Start Caffeine on login" at the Caffeine Preference's window, although the "Disable Screensaver" is not a persistent option and each time I log in I have to check this option again.

With this software installed and enabled, my CPU is now always low and the computer is quiet... the only drawback is that the screen never goes blank and I have to turn off the monitor attached to my laptop manually, but for me it's not really a problem and I much prefer this to finding my laptop hot when I come back after leaving it for 15 minutes.

This is the Caffeine file which I have installed:
https://launchpad.net/~caffeine-developers/+archive/ppa/+files/caffeine_2.4.1%2B464~precise1_all.deb

It's also available for other Ubuntu versions as well:
https://launchpad.net/~caffeine-developers/+archive/ppa/+packages

Revision history for this message
Forage (forage) wrote :

As of Ubuntu 12.10 GNOME remix in combination with AMD CCC 12.11 beta (fglrx 9.010) the issue has disappeared! Note that I did a complete fresh install (not perserving the home folder either) and I have yet to test it with tear free and vsync on, but so far so good.

Revision history for this message
Kellen Hawley (hawleykc) wrote :

I had the same problem using a Ubuntu 12.10/Gnome 3.6/Radeon HD 6650M/fglrx-updates set up. None of the workarounds worked for gnome-shell (although they worked when using Unity).

My workaround was to uninstall gnome-screensaver and replace it with xscreensaver.

Changed in compiz-core:
status: New → Triaged
importance: Undecided → High
milestone: none → 0.9.7.10
Changed in compiz:
status: Triaged → Fix Released
Changed in compiz-core:
status: Triaged → Fix Released
Changed in ubuntu-power-consumption:
status: Confirmed → Fix Released
Changed in compiz (Ubuntu):
status: Triaged → Fix Released
Changed in fglrx-installer (Ubuntu):
status: Confirmed → Fix Released
Changed in fglrx-installer-updates (Ubuntu):
status: Confirmed → Fix Released
Changed in gnome-shell (Ubuntu):
status: Confirmed → Fix Released
Changed in compiz:
status: Fix Released → Triaged
Changed in compiz-core:
status: Fix Released → Triaged
Changed in compiz (Ubuntu):
status: Fix Released → Triaged
Changed in fglrx-installer (Ubuntu):
status: Fix Released → Confirmed
Changed in fglrx-installer-updates (Ubuntu):
status: Fix Released → Confirmed
Changed in gnome-shell (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Jordon Bedwell (envygeeks) wrote :

While we're at it, can anyone update us on the status of this bug in Precise? When I tested it on Quantal it was working exactly as intended with no side-affects like this so I'm wondering if there are plans to fix this soon? Since it seems like it didn't make it into the point.

Revision history for this message
MVNregress (pukakk) wrote :

What version is the fixed one?

I have updated my comiz to 0.9.8.4-bzr3407, but the problem still exists.

What can I do?

Changed in compiz-core:
milestone: 0.9.7.10 → 0.9.7.12
Revision history for this message
Jordon Bedwell (envygeeks) wrote :

Why is this constantly being pushed? And being pushed at all, this is a pretty critical issue that breaks quite a few laptops, I don't even understand why you would ignore an issue like this and push it instead of making it a top priority issue...

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I agree it's critical and I would love to have time to work on it. Hopefully this week.

Please stop complaining about status changes. So many people complain about status changes that I mostly don't bother changing bug status's even when I should, just so no one will complain.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

P.S. Compiz is open source. Canonical is not to blame for things not getting fixed, but everyone is.

Revision history for this message
George (george-labuschagne-gmail) wrote : Re: [Bug 969860] Re: fglrx uses 100% CPU when screen turns off (spinning in glXWaitVideoSyncSGI or glXSwapBuffers)

I have to agree with Jordan.

This fried one of my laptops and actually made me move to kubuntu.

Sent from my BlackBerry® wireless device

-----Original Message-----
From: Jordon Bedwell <email address hidden>
Sender: <email address hidden>
Date: Mon, 19 Nov 2012 07:49:53
To: <email address hidden>
Reply-To: Bug 969860 <email address hidden>
Subject: [Bug 969860] Re: fglrx uses 100% CPU when screen turns off (spinning
 in glXWaitVideoSyncSGI or glXSwapBuffers)

Why is this constantly being pushed? And being pushed at all, this is a
pretty critical issue that breaks quite a few laptops, I don't even
understand why you would ignore an issue like this and push it instead
of making it a top priority issue...

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/969860

Title:
  fglrx uses 100% CPU when screen turns off (spinning in
  glXWaitVideoSyncSGI or glXSwapBuffers)

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz/+bug/969860/+subscriptions

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

OK, I've spent hours testing various options. The bug is much harder to reproduce in Ubuntu 12.10 because the default rendering method in Compiz 0.9.8 is the same as the workaround (1) listed at the top of the bug. To reproduce the bug I had to force the rendering method that Compiz 0.9.7 uses:
    CCSM > OpenGL >
        Framebuffer object = OFF
        Vertex buffer object = OFF
        Always use buffer swapping = OFF

Then I could reproduce the bug. And this time I noticed that glXWaitVideoSyncSGI is not returning. The spin is happening below glXWaitVideoSyncSGI, but above uki_firegl_WaitVBlank (which returns constantly). And because glXWaitVideoSyncSGI is never returning it means we have little hope of even working around the bug in compiz. It's happening 100% inside the fglrx driver, out of reach of compiz.

Interestingly even with the native compiz 0.9.8 rendering method I could reproduce a similar spin in the glxgears process (not compiz). So again, the problem applies to any OpenGL application.

If neither of the workarounds listed at the top of the bug work for you, then please consider uninstalling fglrx and using the default radeon driver instead. And if you haven't already, then upgrading to Ubuntu 12.10 might help, but you don't really need to because that's equivalent to the workaround at the top of the bug.

Finally, I have contacted AMD directly and asked them to review the bug because even their copy has not been touched since it was logged 5 months ago: http://ati.cchtml.com/show_bug.cgi?id=535

Changed in compiz:
status: Triaged → Invalid
Changed in compiz-core:
status: Triaged → Invalid
Changed in fglrx-installer (Ubuntu):
importance: Undecided → Critical
Changed in fglrx-installer-updates (Ubuntu):
importance: Undecided → Critical
Changed in compiz (Ubuntu):
status: Triaged → Invalid
Changed in gnome-shell (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Jordon Bedwell (envygeeks) wrote :

Crap, I had a strong suspicion this was the case because I too didn't experience this bug in 12.10 but 12.10 did not really appeal to my tastes (because of some personal reasons that aren't necessary to this bug.) I don't remember if I ever mentioned that in another bug or not.

Just as a side request if you could, can you please report the default settings for 12.10 for the settings you changed. I actually prefer to keep my desktop tearfree and knowing what those settings are by default in 12.10 will help me a long with plenty of others who want to keep tearfree. (I remember keeping tearfree enabled and not having the problem in 12.10 but the case might have changed since I tested it before Quantal was released and in beta1)

Thanks for taking the time to look into this deeper, and I'm sorry if I sounded angry earlier, I just really wanted updates on the matter and you surely did provide updates that show me peeps care!

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

With the fglrx driver on my laptop using Kubuntu, I have to turn off screen blanking, because every once in a while it causes my system to hang when the screen blanks. I am able to reset gracefully using ALT+PrintScrn+REISUB. I wonder if this is related to the same fglrx bug. I will try running my desktop without OpenGL compositing and see if that makes a difference.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Jordan: I have already mentioned all the settings I've changed in comment #80.

However if you want an optimal tear-free experience then you should not change the compiz settings. The default compiz settings in 12.10 give the optimal tear-free experience, unless it's disabled in your driver settings in which case you should enable it there too.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

AMD tell me the fix is complete and will appear in Catalyst 12.12 (which I think means the December release?).

I'm still confused about the relationship between the Catalyst version number (year.month?) and the fglrx version number that comes from it. But AMD also tell me that it will be made more clear in the version string (from running: glxinfo | grep OpenGL) at least by 12.12.

Changed in compiz:
milestone: 0.9.9.0 → none
Changed in compiz-core:
milestone: 0.9.7.12 → none
Revision history for this message
Forage (forage) wrote :

And for those who can't wait: Ubuntu 12.10 GNOME remix still works like a charm. No compiz, no CPU issues, with tear-free enabled.

Changed in fglrx:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Jordon Bedwell (envygeeks) wrote :

I forgot all about that until you had mentioned the 12.12 driver, for those of you who cannot wait you can get the 12.11 beta (which of course is the 12.12) and install it: http://support.amd.com/us/kbarticles/Pages/AMDCatalyst1211betadriver.aspx

Revision history for this message
Kellen Hawley (hawleykc) wrote :

I can confirm Forage's comment: Ubuntu 12.10 Gnome Remix does not have this problem.
I switched from Ubuntu 12.10 to the Gnome Remix and the problem seemed to solve itself. And I will note that I am running the exact same drivers/programs/extensions that I was when I was experiencing the problem.

Revision history for this message
MVNregress (pukakk) wrote :

I agree with Kellen Hawley.

Gnome Remix couldn't solve this problem.

Revision history for this message
MVNregress (pukakk) wrote :

Oops.. Sorry, I mean.. disagree.

I experience High CPU usage in Gnome Remix, too

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Gnome probably does not suffer from this bug if it doesn't have any vsync enabled by default. That's equivalent to "WORKAROUND (2)" listed at the top of the bug.

Revision history for this message
Forage (forage) wrote :

@Daniel: That does not explain why Gnome Shell users had the same issue earlier. For the record, I have vsync enabled in CCC and no high CPU issue to be seen.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Regardless of what is affected and what is not... AMD have confirmed their driver is to blame and they have a fix.

If Gnome is not affected, that's awesome. But we don't need to worry about why.

Revision history for this message
Aurélien Leblond (blablack) wrote :

Quick questions - Once the driver is released by AMD:
- Will it be available in Ubuntu 12.10?
- Which version of the driver will be updated: fglrx or fglrx-updates?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

blablack: I'm not aware of AMD sharing their release schedule with us.

When it is available from AMD, you should keep an eye on:
https://launchpad.net/ubuntu/+source/fglrx-installer
https://launchpad.net/ubuntu/+source/fglrx-installer-updates

Our package maintainer might have more info:
Alberto Milone <email address hidden>

Revision history for this message
Vitaly Tskhovrebov (viialy) wrote :

Bug affects me as well.

Changed in compiz (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Jordon Bedwell (envygeeks) wrote :

This is an upstream bug, and it's been fixed in 13.1 so please either install 13.1 or wait until Ubuntu updates fglrx in the repository (even though they are practically the same -- minus a few differences -- if you build them.)

Changed in compiz (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Patrick Callahan (pxc) wrote :

I'm running Kubuntu 12.10 and this bug continues to affect me with 13.1, using .deb packages I built automatically from their 13.1 installer.

It looks like this is just as ‘fixed’ as their ‘Konsole resize causes X crash’ bug.

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Patrick, does using Xrender as kwin's compositing backend work as a workaround? That's how I resolved my blank screen freezes using previous versions of the fglrx driver. I haven't been able to get a freeze using 13.1 + kwin OpenGL backend yet, but we'll see...

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Patrick, is this the bug you are experiencing?: http://ati.cchtml.com/show_bug.cgi?id=553

This is what I'm currently experiencing using KDE + fglrx drivers, unless I use the xrender backend or disable compositing altogether. Unfortunately, using xrender causes issues with windowed OpenGL apps not updating their screen contents :(

Revision history for this message
Marcos Lans (markooss) wrote :

WORKAROUND (2):
1. Run ccsm (from package compizconfig-settings-manager)
2. In OpenGL > Sync To VBlank = OFF

worked for me in Ubuntu 12.04
Thanks

Revision history for this message
David (daved314) wrote :

Either the upstream bug was re-introduced or never really fixed because I'm running the amd-catalyst-13.8 beta2 version (fglrx 13.2000). As soon as the screen shuts off, the CPU usages spikes to 100%. Neither of the workarounds work for me. I've been forced to just turn off X at night.

I've noticed the problem as well if I run xbmc as a standalone. As soon as the screen is shut off, the xbmc.bin process jumps to 100% cpu. The same is true when trying with fvwm2 or xfce4 as well.

can we get upstream to re-open the bug?

Revision history for this message
Forage (forage) wrote :

No issues with amd-catalyst-13.8 beta2 (since 12.12 for that matter) in combination with GNOME Shell (3.8) on Ubuntu GNOME 13.04 for me.

@David: Are you using Unity or GNOME Shell and which version of Ubuntu are you running?

Revision history for this message
David (daved314) wrote :

I'm running Ubuntu 12.10 quantal with the amd-catalyst-13.8 beta2 drivers downloaded from the AMD website and compiled/installed on the system. I've not tried GNOME but I've seen this in the other xsession environments. The primary use of this box is running a standalone xbmc instance though. Whenever the screen is shut off (either by standard delay or xset dpms force off) the cpu usage shoots up to 100%. The card is a Radeon HD 7310

papukaija (papukaija)
tags: added: battery-power-consumption quantal
Revision history for this message
Ken Phillis Jr (kphillisjr) wrote :

Just to check, Can anyone confirm that this is still a problem with the Catalyst 13.11 Beta drivers?

http://support.amd.com/en-us/kb-articles/Pages/Latest-LINUX-Beta-Driver.aspx

Revision history for this message
David (daved314) wrote :

I've just upgraded to the Catalyst 13.11 Beta Drivers linked in #104 and my CPU utilization issue has gone away. When the monitor shuts off, the CPU usage goes down instead of to 100%

I'm going to say "fixed for me with latest 13.11 drivers"

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

OK then. I haven't retested myself but trust both comment #105 and the upstream bug info. Therefore fix released somewhere around:

fglrx-installer (2:13.101-0ubuntu1) saucy; urgency=low
fglrx-installer-updates (2:13.101-0ubuntu1) saucy; urgency=low

Changed in fglrx-installer (Ubuntu):
status: Confirmed → Fix Released
Changed in fglrx-installer-updates (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Peleg (freepeleg) wrote :

I am using Dell latitude e7440, Ubuntu trusty, having the same problem. Every time I lock my screen using <Win-key>-L, after a few seconds my vent goes crazy and the temperature rises to 80+ Celsius.

I could not run the `dstack` file properly. The output of `sh ./dstack compiz > compizstack.txt` was
====
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
/home/peleg/2417: No such file or directory.
Thread ID 1 not known.
/tmp/dstackscript4955:4: Error in sourced command file:
No stack.
====

The output of `sudo sh ./dstack compiz > compizstack.txt` was
====
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
185 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
====

My system info:

* Ubuntu 14.04.3 LTS (trusty)
* Architecture: 64 bit
* Kernel version: 3.16.0-40-generic
* Dell E7440
* Bios version: A14

Revision history for this message
V-Mark (vertesmark) wrote :

I faced with exactly the same problem with different hardware:

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-51
- 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

I do not have Catalyst Center (my GPU is Intel), but
The solution helped:

"WORKAROUND (2):
1. Run ccsm (from package compizconfig-settings-manager)
2. In OpenGL > Sync To VBlank = OFF"

This made my 100% processor usage to 70%
and from workaround 1:

"4. Run "ccsm"
5. In Workarounds, enable "Force full screen redraw (buffer swap) on repaint"."

solved my problem totally.

All these chips (and problems) are more similar than we think!

Revision history for this message
V-Mark (vertesmark) wrote :

... unfortunately I realized that my problem begins NOT with screensaver activation, but screen LOCK activation.
During test I switched off the LOCK, this is why my problem seemed to be solved.

I found another bug report which describes my problem: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1322751

Revision history for this message
Khurshid Alam (khurshid-alam) wrote :

This bug has returned for me on Xenial for Intel 965 GMA and many other older intel video drivers.

Revision history for this message
Forage (forage) wrote :

@Khurshid: In which case it's a different bug which should be reported as a new one separately. This one is about AMD/ATI cards/drivers, not Intel.

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

Other bug subscribers

Remote bug watches

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