GNOME Bugzilla – Bug 578254
mixer_applet2 is utilizing100% cpu usage after suspend/resume case
Last modified: 2015-09-26 04:44:11 UTC
Problem: mixer_applet2 is utilizing 100% CPU usage after doing suspend/resume. Sound is working fine. Step to reproduce: 1. Just do suspend 2. Then resume 3. Observer the "top" utility. #top -p 4508 -d 3 [...] -- top - 12:58:11 up 1:20, 3 users, load average: 1.05, 1.28, 1.37 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 37.3%us, 20.7%sy, 0.0%ni, 41.7%id, 0.0%wa, 0.3%hi, 0.0%si, 0.0%st Mem: 3095632k total, 1498188k used, 1597444k free, 63628k buffers Swap: 4000144k total, 0k used, 4000144k free, 825724k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4508 person 20 0 55436 19m 14m S 100 0.6 17:34.82 mixer_applet2 -- Actual Result: mixer_applet2 is taking 100 CPU usage Expected Result: CPU usage should be reasonable. Debug Information: [...] -- (gdb) thread apply all bt
+ Trace 214258
Observation, Extra Information: It happens mostly after doing Suspend/Resume activity. I have secondary USB sound card. I have also observed, when i doing resume, i may/may not use my secondary USB card. OS Info: NonfreeKernelModules: nvidia SourcePackage: gnome-applets Package: gnome-applets 2.26.0-0ubuntu4 PackageArchitecture: i386 ProblemType: Bug Architecture: i386 ProcEnviron: LANG=en_IN SHELL=/bin/bash Uname: Linux 2.6.28-11-generic i686 DistroRelease: Ubuntu 9.04
There are similar Bug 519388 but in different case. I have tested that one also, it's not happening during inserting/removing secondary USB sound card.
Originally reported on LP [1]. [1] https://bugs.launchpad.net/gnome-applets/+bug/339187
I'm hitting this too today with 2.26.1-0ubuntu1 in Ubuntu Jaunty. I have not suspended this machine but I did insert a USB headset this morning and that may have provoked the problem.
+ Trace 216039
In case it helps: (gdb) p *fds $2 = {fd = 3, events = 1, revents = 0} mixer_app 26046 mbp 0u CHR 1,3 4423 /dev/null mixer_app 26046 mbp 1u CHR 1,3 4423 /dev/null mixer_app 26046 mbp 2u CHR 1,3 4423 /dev/null mixer_app 26046 mbp 3u unix 0xffff880208132680 317249 socket mixer_app 26046 mbp 4r FIFO 0,6 317259 pipe mixer_app 26046 mbp 5w FIFO 0,6 317259 pipe mixer_app 26046 mbp 6r FIFO 0,6 317260 pipe mixer_app 26046 mbp 7w FIFO 0,6 317260 pipe mixer_app 26046 mbp 8r FIFO 0,6 317261 pipe mixer_app 26046 mbp 9w FIFO 0,6 317261 pipe mixer_app 26046 mbp 10u unix 0xffff880208133700 317269 /tmp/orbit-mbp/linc-65be-0-4e16813f3f2c mixer_app 26046 mbp 11u unix 0xffff880208133180 317267 socket mixer_app 26046 mbp 12u unix 0xffff880208166940 317277 /tmp/orbit-mbp/linc-65be-0-4e16813f3f2c mixer_app 26046 mbp 13u unix 0xffff880208167180 317278 socket mixer_app 26046 mbp 14u unix 0xffff880208167700 317281 socket mixer_app 26046 mbp 15u unix 0xffff8800c35cc000 317284 /tmp/orbit-mbp/linc-65be-0-4e16813f3f2c mixer_app 26046 mbp 16u unix 0xffff880037918840 317385 socket mixer_app 26046 mbp 17u unix 0xffff88020911b9c0 317789 /tmp/orbit-mbp/linc-65be-0-4e16813f3f2c mixer_app 26046 mbp 18u unix 0xffff8800c4475e40 317837 socket mixer_app 26046 mbp 19r FIFO 0,6 317962 pipe mixer_app 26046 mbp 20w FIFO 0,6 317962 pipe mixer_app 26046 mbp 21u REG 252,2 12288 4262507 /home/mbp/.cache/event-sound-cache.tdb.1e96b25e364319541b412f6e4911036e.x86_64-pc-linux-gnu mixer_app 26046 mbp 22u CHR 116,6 314992 /dev/snd/controlC1 (deleted)
I have this too with my USB headset. I have played around with GDB and came up with the following: The function that constantly loops is task_monitor_alsa in gst-plugins-base/ext/alsa/gstalsamixer.c. In that code, the function "snd_mixer_poll_descriptors" is used to get a list of struct poll_fd elements from the alsa mixer data structure. However, the file descriptor this call returns points to a file which has been deleted and re-made (that's why Martin Pool's post says "(deleted)" for #22). The poll(2) function is then used to wait for events on this file descriptor and another one. This immediately returns with POLLERR,POLLHUP,POLLNVAL in the revents field, because the file it tries to access no longer exists. The snd_mixer_poll_descriptors_revents function then gathers all returned events (among which) POLLERR and POLLNVAL. However, the code does not do anything with these statuses, it simply checks for POLLIN or POLLPRI and throws the rest away. Killing and restarting mixer_applet uses the new (working) /dev/snd/control* file, which properly blocks. I'm not sure how to fix this, because it's an alsa issue, not a gnome-applets one, but I think the code should check for POLLNVAL and POLLERR results after the check, or by fstat'ing the file descriptors before calling poll().
Oops. I meant it's a GST issue, more exactly in the ALSA plugin.
Speaking of which, this is a duplicate of GStreamer bug #507527. I'll post my observation there too. Sorry for the disturbance :)