User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 When I play my album in Rhythmbox, after a while it will suddenly use lots of CPU and memory (as can be seen in the top screenshot). There is no sound afterwards (I think pulseaudio dies as well). Reproducible: Sometimes Steps to Reproduce: 1. Open up rhythmbox 2. Select album 3. Play and wait Actual Results: After several minutes of playing, the playing stops and rhythmbox freezes, using up lots of CPU and memory, causing linux to freeze as well. Expected Results: Should continue playing with no problem. After killing rhythmbox, i need to restart pulseaudio to restore sound.
Created attachment 320385 [details] Screenshot of top when rhythmbox has frozen The CPU isn't high in that screenshot for rhythmbox because of the screenshot tool I think.
It is likely that it may be pulseaudio that has crashed?
Hmm... E: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 18446744073709517728 bytes (384307168025 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. N: module-alsa-sink.c: Increasing wakeup watermark to 34.00 ms Soft CPU time limit exhausted, terminating. Hard CPU time limit exhausted, terminating forcibly. Aborted
I'm experiencing a similar problem. I frequently play CDs while I work. On Fedora 9 and previous versions, this has never been a problem. But with Fedora 10, When I put a CD in the drive, the Rhythmbox app pops up. It seems like overkill just to play a CD, but whatever. Anyway, it and/or pulsaudio seem to suck up a ton of CPU time and the system load slowly climbs. Screen refreshes start taking several seconds and eventually the mouse cursor and keyboard start to freeze intermittently. Finally Rhythmbox itself crashes and sends a bug report. Unfortunately, it leaves the system in a screwed up state - top shows the load dropping back to normal but everything is very sluggish and freezes intermittently until I completely reboot the system. The messages log shows stuff like this: Dec 27 18:09:00 ixtl kernel: end_request: I/O error, dev sr0, sector 0 Dec 27 18:09:00 ixtl kernel: __ratelimit: 23 callbacks suppressed Dec 27 18:09:00 ixtl kernel: Buffer I/O error on device sr0, logical block 0 Dec 27 18:09:00 ixtl kernel: Buffer I/O error on device sr0, logical block 1 Dec 27 18:09:00 ixtl kernel: Buffer I/O error on device sr0, logical block 2 Dec 27 18:09:00 ixtl kernel: Buffer I/O error on device sr0, logical block 3 Dec 27 18:09:00 ixtl kernel: end_request: I/O error, dev sr0, sector 0 Dec 27 18:09:00 ixtl kernel: Buffer I/O error on device sr0, logical block 0 Dec 27 18:09:25 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 18:25:45 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 18:37:05 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 18:40:26 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 18:43:57 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 18:49:30 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 18:52:15 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 18:54:52 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 19:01:04 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms Dec 27 19:07:40 ixtl pulseaudio[2755]: module-alsa-sink.c: Increasing wakeup watermark to 354.01 ms
(In reply to comment #2) > It is likely that it may be pulseaudio that has crashed? Yes. There were known bugs in the PulseAudio GStreamer plugin which would cause deadlocks and hangs when the daemon went away. Those are fixed in F-10 and rawhide.