Bug 418571 - mixer_applet2 using 99% CPU
Summary: mixer_applet2 using 99% CPU
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-applets
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
: 476354 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-12-10 18:10 UTC by Eric Sandeen
Modified: 2010-07-29 02:12 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-31 14:16:09 UTC

Attachments (Terms of Use)

Description Eric Sandeen 2007-12-10 18:10:58 UTC
Description of problem:

mixer_applet2 is using 99-100% of the cpu on my system until I restart it
(restart the applet, that is):

top - 12:04:44 up 20 days, 18:51, 30 users,  load average: 5.09, 2.60, 1.83
Tasks: 269 total,   1 running, 265 sleeping,   2 stopped,   1 zombie
Cpu(s): 29.9%us, 27.0%sy,  0.0%ni,  4.5%id, 36.2%wa,  0.6%hi,  1.8%si,  0.0%st
Mem:   1026908k total,  1016616k used,    10292k free,       44k buffers
Swap:  2048276k total,   633516k used,  1414760k free,   102300k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
17955 esandeen  20   0  310m 7136 5524 S  100  0.7   4009:55 mixer_applet2     
 2855 root      20   0  188m  65m 7456 S    5  6.6  89:31.16 X                 
 8897 root      20   0  374m 162m 6256 D    2 16.2   0:05.96 yum               
  471 root      20   0     0    0    0 S    2  0.0   1:47.78 nfsd              

Version-Release number of selected component (if applicable):

How reproducible:
Run mixer_applet2 & wait, I guess...

[root@neon linux-2.6.24-rc3]# ps ax | grep mixer
17955 ?        Sl   4011:14 /usr/libexec/mixer_applet2
--oaf-activate-iid=OAFIID:GNOME_MixerApplet_Factory --oaf-ior-fd=22
[root@neon linux-2.6.24-rc3]# strace -p 17955
Process 17955 attached - interrupt to quit
read(3, 0x635404, 4096)                 = -1 EAGAIN (Resource temporarily
[root@neon linux-2.6.24-rc3]# ls -l /proc/17955/fd/3 
lrwx------ 1 esandeen esandeen 64 2007-12-10 12:09 /proc/17955/fd/3 ->

if that helps at all...


Comment 1 Bug Zapper 2008-11-26 08:56:14 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 2 Andre Robatino 2008-11-28 03:19:49 UTC
I am seeing ridiculously high CPU usage by mixer_applet2 starting with a clean install of x86_64 F10.  It didn't happen on i386 F9.  For example, it uses up over 70% of the CPU while playing a DVD with vlc (with vlc and related processes taking up most of the rest).  Please update the Version to 10.

Comment 3 William Lovaton 2008-12-01 21:09:22 UTC
Well, I am seeing this problem in Fedora 10 after resuming from suspend to ram.  Logging out and then log back in solves it.

Reporter, can you confirm this? maybe it's the same issue I am seeing here.

Comment 4 Eric Sandeen 2008-12-01 21:14:26 UTC
I have no f10 boxes with sound yet, so can't confirm myself :)

Comment 5 Ray Strode [halfline] 2008-12-15 17:36:14 UTC
*** Bug 476354 has been marked as a duplicate of this bug. ***

Comment 6 Eric Sandeen 2009-03-02 16:37:53 UTC
I still see this on F10.  No suspend involved.

Comment 7 Feng Yu 2009-03-15 23:59:15 UTC
I see this after suspend -- during suspend I unplugged an external USB soundcard.

The applet itself seems to be functional though.

Comment 8 Felix Möller 2009-04-09 20:36:40 UTC
this has been reported at http://bugzilla.gnome.org/show_bug.cgi?id=519388

the patch is supposed to be at http://bugzilla.gnome.org/attachment.cgi?id=89596&action=view but a slightly modified version was commited according to http://bugzilla.gnome.org/show_bug.cgi?id=167606#c10

Comment 9 Braden McDaniel 2009-06-06 15:29:10 UTC
I'm seeing mixer_applet2 consume all of a CPU on both F9 and F10. On neither of these machines am I using a USB soundcard nor am I using suspend.

I've just started seeing this in the last month or so; so I think some update has broadened the impact of this bug.

Comment 10 William Lovaton 2009-07-17 21:14:47 UTC
I haven't seen this bug for a while?? can you reproduce this with F11?

Comment 11 Braden McDaniel 2009-07-17 21:48:24 UTC
mixer_applet2 isn't part of gnome-applets in F11.

Comment 12 Brent R Brian 2009-07-17 21:58:18 UTC
I have not seen this on F11.

Comment 13 Ray Strode [halfline] 2009-07-31 14:16:09 UTC
Let's go ahead and close this out now.

Comment 14 Nathan Gibson 2010-07-29 02:12:59 UTC
Just a comment. I ran accross this on RHEL5 with VMWare workstation 6.5.4.
mixer_applet2 CPU went through the roof.
Occurred while booting new VM and workstation was detecting audio devices on vm boot.
So steps to reproduce may be 

Run mixer_applet2 & and boot VM
not just
Run mixer_applet2 & wait

It may be a race condition and caused by any number of other audio related apps too.

just killed process and it requested auto start just as above.
Perhaps somebody wants to implement a watchdog to do this automatically and log it when it occurs?

Note You need to log in before you can comment on or make changes to this bug.