Description of problem: esd runaway process Version-Release number of selected component (if applicable): esound-1:0.2.37-1.fc7 How reproducible: Every reboot Steps to Reproduce: 1. Reboot into 2.6.21-rc3 2. All is well 3. after an hour of work: email (thunderbird), web browsing (firefox), etc. Actual results: Snapshot of w: [root@mozart log]# w 20:25:18 up 2:34, 1 user, load average: 2.74, 2.43, 2.21 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kaune pts/1 :0.0 17:53 0.00s 0.04s 1.51s gnome-terminal nothing else is going on except this web browser entering the bugzilla data. Snapshot of top: top - 20:21:43 up 2:30, 1 user, load average: 2.21, 2.17, 2.10 Tasks: 140 total, 4 running, 135 sleeping, 0 stopped, 1 zombie Cpu(s): 17.6%us, 82.4%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1036268k total, 749316k used, 286952k free, 48760k buffers Swap: 2015992k total, 0k used, 2015992k free, 515148k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3687 kaune 25 0 3716 1688 980 R 98.5 0.2 142:23.29 esd 3700 kaune 15 0 39464 14m 10m R 0.7 1.4 0:01.32 gnome-terminal 3574 root 15 0 107m 20m 7756 S 0.3 2.0 1:12.17 Xorg 3663 kaune 15 0 12664 4132 3264 S 0.3 0.4 0:17.76 at-spi-registry 4622 root 15 0 2192 1008 772 R 0.3 0.1 0:00.02 top 1 root 15 0 2128 632 544 S 0.0 0.1 0:00.47 init ... esd is running full tilt and no real warning. I have looked in /var/log/messages and do not know where else to get a clue as to why it has run away. Expected results: Obviously, it is not expected to be the cause of a 100% cpu utilization. Additional info: I am fully up to date as far as yum update provides at this writing. This has been occuring for at least the last week. My solution is to kill -TERM the pid- but ... My system is the Fedora development on a P4 2.4 GHz with 1Gb RAM. I am not running the distributed kernel, but rather a "pure" 2.6.21-rc3 kernel, because so far, I have issues with my hda, hdb and sata_via sda, sdb and scsi drive sdc being found properly. (all are found as sd? and not as my setup expects, hence the boot panics) Naturally, this is a whole other issue I want to figure out and will file under a separate bug).
It appears the new alsa updates may have resolved whatever issue this was. The problem has disappeared following the update this morning. Thank you Kirk C Aune