F14: high temperatures after coming back from hibernate

Gordon Messmer yinyang at eburg.com
Tue Nov 9 21:32:34 UTC 2010


On 11/08/2010 07:22 PM, Ranjan Maitra wrote:
> % strace -f -s 256 -p 1589
>
> The following keeps on scrolling:
>
> [pid  1589] ppoll([{fd=5, events=POLLIN}, {fd=21, events=POLLIN},
> {fd=9, events=0}, {fd=4, events=POLLIN}, {fd=20, events=POLLIN},
> {fd=26, events=POLLIN}, {fd=31, events=POLLIN|POLLERR|POLLHUP},
> {fd=31, events=0}, {fd=30, events=POLLIN}, {fd=29, events=POLLIN},
> {fd=22, events=POLLIN}, {fd=25, events=POLLIN}, {fd=16,
> events=POLLIN}, {fd=19, events=POLLIN}, {fd=15,
> events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=0}, {fd=14,
> events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}], 19,
> NULL, NULL, 8) = 1 ([{fd=9, revents=POLLHUP}])
>
> Killing pulseaudio (the process) seems to take care of it, and the
> temperature cools.

It's important to be exact here.  That is a single line from the output 
of strace.  Is every single line of output identical?  Do they all end 
with "= 1 ([{fd=9, revents=POLLHUP}])"?

If so, that indicates that pulseaudio has lost connection to something 
which was attached to file descriptor 9.  It's not clear to me where 
this bug is.

First, I would assume that any time that pulseaudio gets HUP on one of 
its fds, it should close that fd and stop polling it.

However, pulseaudio is polling fd 9 with no "events" requested.  In that 
case, I believe that either glibc or Linux (the kernel) is at fault.  No 
events should be returned for that fd.  The documentation isn't 
perfectly clear on what actually happens when no events are specified, 
so this may be a bug or it may not be.


More information about the users mailing list