Bug 238680

I'm having this issue as well. Seems that other distributions are struggling
with similar issues. Any word of advice? It would be nice to have this fixed
before FC 7 is released.

Christian. 

Is more than one copy of esound running when you see that problem? Could you
please test with esound-0.2.38-1 I pushed to rawhide today?

If the problem persists, could you please attach a backtrace of the hang, with
the appropriate -debuginfo packages installed?

(In reply to comment #2)
> Is more than one copy of esound running when you see that problem?

nope, there's only one esd process.

> Could you
> please test with esound-0.2.38-1 I pushed to rawhide today?

esound-svn I mentioned was essentially 0.2.38. I cannot see the new package on
the mirrors yet but the problem exists with 0.2.38 packages I've built myself.

> If the problem persists, could you please attach a backtrace of the hang, with
> the appropriate -debuginfo packages installed?

I've attached backtraces of both esd and a hanged gnome-panel to:
http://bugzilla.gnome.org/show_bug.cgi?id=431711 . Are they good enough?

Which version of alsa-lib and the kernel are you using?

The same bug was report in ALSA's bug tracker:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1306
and it's supposed to have been fixed in the kernel drivers version 1.0.9a

If it still happens, it's probably a bug in the driver/ALSA kernel-side.
snd_pcm_wait_nocheck shouldn't be hanging...

(In reply to comment #4)
> Which version of alsa-lib and the kernel are you using?

Currently alsa-lib-1.0.14-0.4.rc3.fc7 on kernel-PAE-2.6.21-1.3142.fc7

> The same bug was report in ALSA's bug tracker:
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1306
> and it's supposed to have been fixed in the kernel drivers version 1.0.9a

Yes, I saw it mentioned on a ubuntu bug too, but this problem didn't exist with
FC6. Checking the dmesg outputs between fc6 and fc7 kernels, with fc6 I had this
message:
hda_codec: Unknown model for ALC861, trying auto-probe from BIOS...

With fc7 I have this instead:
hda_intel: azx_get_response timeout, switching to polling mode...

> If it still happens, it's probably a bug in the driver/ALSA kernel-side.
> snd_pcm_wait_nocheck shouldn't be hanging...

I also think this is alsa related. I've filed this agains esd partly because I
don't have any sound problems (that i'm aware of) besides this esd hang issue,
and partly because I considered esd hanging the session for whatever reason
being a bug on its own.

(In reply to comment #5)
> (In reply to comment #4)
> > Which version of alsa-lib and the kernel are you using?
> 
> Currently alsa-lib-1.0.14-0.4.rc3.fc7 on kernel-PAE-2.6.21-1.3142.fc7

Should be more than new enough.

> > The same bug was report in ALSA's bug tracker:
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1306
> > and it's supposed to have been fixed in the kernel drivers version 1.0.9a
> 
> Yes, I saw it mentioned on a ubuntu bug too, but this problem didn't exist with
> FC6. Checking the dmesg outputs between fc6 and fc7 kernels, with fc6 I had this
> message:
> hda_codec: Unknown model for ALC861, trying auto-probe from BIOS...
> 
> With fc7 I have this instead:
> hda_intel: azx_get_response timeout, switching to polling mode...

That's probably not right...

> > If it still happens, it's probably a bug in the driver/ALSA kernel-side.
> > snd_pcm_wait_nocheck shouldn't be hanging...
> 
> I also think this is alsa related. I've filed this agains esd partly because I
> don't have any sound problems (that i'm aware of) besides this esd hang issue,
> and partly because I considered esd hanging the session for whatever reason
> being a bug on its own.

esd isn't hanging because of its own fault, it's hanging because
snd_pcm_wait_nocheck is hanging. snd_pcm_wait_nocheck shouldn't hang, and that's
a driver and/or alsa-lib problem.

As for the applications hanging, as mentioned on the upstream bugzilla, it's a
shortcoming of the esound architecture, there's no easy way to fix it,
unfortunately.

Reassigning to alsa-lib for first pass at debugging. Martin, do you think it
smells like a driver problem?

It's hard to say. What ALSA device does the esd use? hw or plughw? It definitely
should use the "default" device which provides HW/SW mixing and so on.

I believe it uses "hw" by default, so it might be something else using the
device as well. Which devices would Sertaç need to grep for in lsof to see what
other app is using the sound device?

Should it simply use plughw instead?

Adding Cameron to the report, because he hit this today.

I see this same thing when I have esd and play system sound enabled.  As for
hardware I have Intel ICH6 with AD1981B.  

esd defaults to "hw", and neither using plughw with "esd -d" nor updating
alsa-lib to rc4 made any difference.

output of "/usr/sbin/lsof +D /dev/snd":
COMMAND     PID   USER   FD   TYPE DEVICE SIZE NODE NAME
gnome-set 12829 sertac   23u   CHR  116,8      4662 /dev/snd/controlC0
mixer_app 12840 sertac   17u   CHR  116,8      4662 /dev/snd/controlC0
esd       12852 sertac  mem    CHR  116,6      4649 /dev/snd/pcmC0D0p
esd       12852 sertac    5r   CHR  116,2      4072 /dev/snd/timer
esd       12852 sertac    6u   CHR  116,6      4649 /dev/snd/pcmC0D0p
esd       12852 sertac    7u   CHR  116,8      4662 /dev/snd/controlC0

*** Bug 242059 has been marked as a duplicate of this bug. ***

This does fix the issue until its properly resolved...

edit /etc/esd.conf
change
default_options=
to
default_options=-nobeeps -unix -as 2

*** Bug 243068 has been marked as a duplicate of this bug. ***

As far as the original issue the esd daemon is having, that's one issue.  But
even if esd is malfunctioning, that by itself should not take the whole desktop
down with it.

I just suffered through an FC6 to FC7 upgrade, where the desktop failed to come
up at all.  I eventually discovered that a whole bunch of processes started by
gnome-session where hung in a connect() call to /tmp/.esd/socket, and nothing
would go any further until I kill esd, which had its socket open, but was not
accepting any connection.

After some peeking and poking, esd seems to be running after I manually deleted
$HOME/.esd_auth; unfortunately I did not keep a copy of the original file that
gave esd indigestion, however:

The problem is with the esound library.  It opens a connection to
/tmp/.esd/socket without employing any timeout whatsoever.  If esd gets stuck,
everyone will wait forever, to connect to esd, and the whole desktop freezes.

This is bad design.

The correct solution is to employ a reasonable timeout, say 10 seconds, and 
if the connection does not go through, give up and fall back to plan B.

*** Bug 243135 has been marked as a duplicate of this bug. ***

Boosting priority, since this bug makes Fedora 7 unusable to many users. 
Currently, this is one of two bugs blocking creating a Fedora 7 image for coLinux.

(In reply to comment #14)
> This does fix the issue until its properly resolved...
> 
> edit /etc/esd.conf
> change
> default_options=
> to
> default_options=-nobeeps -unix -as 2
> 

this "fix" seem to work fine here thx.

*** Bug 243546 has been marked as a duplicate of this bug. ***

there's probably a race condition in snd_pcm_drain. As a workaround, we can use
snd_pcm_drop.

Created attachment 156695 [details]
there's a patch to esound

Test packages built against rawhide are available here (and in rawhide shortly):
http://koji.fedoraproject.org/koji/taskinfo?taskID=33235

Please test.

the patch in comment #22 solved the esd issue, thanks.

is there an open bug to track the original problem?

(In reply to comment #24)
> the patch in comment #22 solved the esd issue, thanks.
> 
> is there an open bug to track the original problem?

If that's the actual problem (a bug in alsa-lib or alsa core), we'll keep this
bug opened.

Thanks.  I can also confirm the test packages from comment #23 solved the
problem for the two of my Fedora 7 installations.  (I have not checked the third
yet.)

Bill

*** Bug 243758 has been marked as a duplicate of this bug. ***

I installed the test package in comment #23.  This did not fix my problem.  I
enabled sounds, rebooted, and used my system.  That worked fine.  However, I
rebooted again, and then my login hung as before.

(In reply to comment #28)
> I installed the test package in comment #23.  This did not fix my problem.  I
> enabled sounds, rebooted, and used my system.  That worked fine.  However, I
> rebooted again, and then my login hung as before.

If the problem still occurs, could you please get a backtrace with the debuginfo
packages installed, as it's either the same problem (ie. hanging at the same
place), or there's another bug that needs to be worked on.

How do I get the backtrace?

(In reply to comment #30)
> How do I get the backtrace?

Following the instructions at:
http://fedoraproject.org/wiki/StackTraces

You'll probably need to install esound-debuginfo and alsa-lib-debuginfo

The patch package does not solve my problem.  Processes are still hanging when
playing sounds.  I would have a backtrace, but hard locks when switching to a
virtual console are blocking me (Lenovo T60).  

when your system hangs, switch to the console (ctrl+alt+f1), search for pid of
esd process (ps axf) and attach gdb to it (gdb --pid=xxxx)

*** Bug 242376 has been marked as a duplicate of this bug. ***

Created attachment 157059 [details]
backtrace of esd from my hung session

This is a backtrace of esd on my hung login after enabling sound events.  I
have the patch from comment 23 applied.

esound-0.2.38-2.fc8.i386.rpm
esound-debuginfo-0.2.38-2.fc8.i386.rpm

(In reply to comment #35)
> Created an attachment (id=157059) [edit]
> backtrace of esd from my hung session
> 
> This is a backtrace of esd on my hung login after enabling sound events.  I
> have the patch from comment 23 applied.

You don't use the patched version or the patch isn't applied right.

~/>rpm -qa | grep esound
esound-debuginfo-0.2.38-2.fc8
esound-libs-0.2.38-1.fc7
esound-0.2.38-2.fc8
esound-devel-0.2.38-1.fc7

OK, I see that there are additional esound rpm's: esound-libs and esound-devel.
 I'll install them and try again.

Can anybody else reproduce the problem with the updated packages?
If not, I'll push an F7 update, and file the bug upstream.

The patch seems to be working on my system now.

I can still reproduce the problem with the patched packages.  I will try to
provide backtraces, but other issues are making that difficult (hardlocks when
switching virtual consoles).

After a reboot, is seems the problem is resolved.  Maybe I had a stale process
hanging around or something.  Whatever.  It works now.

esound-0.2.38-2.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

*** Bug 230758 has been marked as a duplicate of this bug. ***

I can also confirm, that the patched packages resolve the hang of esd after
login. One thing I encountered though was, that on one system (i386) esd hangs
again after a re-login. On my other x86_64 system esd works perfectly fine now.

Jo

(In reply to comment #42)
> esound-0.2.38-2.fc7 has been pushed to the Fedora 7 testing repository.  If
problems still persist, please make note of it in this bug report.

Bastien, you may put this package into stable, not testing...

(In reply to comment #45)
> Bastien, you may put this package into stable, not testing...

Yeah, sounds like it's cooked. Pushed now.

esound-0.2.38-2.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

works fine, thx

I am using Fedora 7 x86_64. After applying the esound-0.2.38-2.fc7 patch and
enabling the sound again, logging in is fine. However, my system now hangs when
logging out. The screen freezes, can't get any vty sessions, can't even logon
from another box using ssh. After disabling sounds, all is OK again. 

Anyone else with similar/same symptoms?

Please let me know what information I can provide to get this resolved.

Thanks,
Bas.

(In reply to comment #49)
> I am using Fedora 7 x86_64. After applying the esound-0.2.38-2.fc7 patch and
> enabling the sound again, logging in is fine. However, my system now hangs when
> logging out. The screen freezes, can't get any vty sessions, can't even logon
> from another box using ssh. After disabling sounds, all is OK again. 
> 
> Anyone else with similar/same symptoms?
> 
> Please let me know what information I can provide to get this resolved.

That's probably a kernel or X crash, nothing to do with this problem. Please
open a new bug about it, against the kernel.

Well, if you say it has nothing to with this bug, fine with me. However  to me
it looks like there is some sort of a relation. I had exactly the same problem
when logging in with sound events enabled. After the 0.2.38-2 patch, logging in
is fine, but now I have exactly the same problem when logging out. If I disable
the sounds (the installation default) and booting, all works OK again and no
hangs whatsoever.

I have no idea how/where to log kernel/X bugs, so I guess I keep the sounds off
until someone else comes across it and Fedora 7 becomes a bit more stable.

(In reply to comment #51)
> Well, if you say it has nothing to with this bug, fine with me. However  to me
> it looks like there is some sort of a relation. I had exactly the same problem
> when logging in with sound events enabled. After the 0.2.38-2 patch, logging in
> is fine, but now I have exactly the same problem when logging out. If I disable
> the sounds (the installation default) and booting, all works OK again and no
> hangs whatsoever.

You're the first person to mention this particular problem, and esound shouldn't
hard-lock the machine, so it's unlikely to be directly related to this bug.

> I have no idea how/where to log kernel/X bugs, so I guess I keep the sounds off
> until someone else comes across it and Fedora 7 becomes a bit more stable.

File a bug, the assignee will surely be kind enough to point you in the right
direction.

Either the component or the status of this bug (but possibly both) are incorrect
at the moment.

Nice to have this esd bug fixed finally.  Thanks.

I'm also having problems with my log out freezing and have filed a bug here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245522

Join me if this is an issue for you.