On Wed, 21.05.08 21:11, Kevin Kofler (kevin.kofler@xxxxxxxxx) wrote: > > Lennart Poettering <mzerqung <at> 0pointer.de> writes: > > Hmm, this bug seems to be triggered only by KDE. Apparently in KDE PA > > is not configured for module-x11-xsmp? (could anyone who actually runs > > KDE check this?) > > Sounds like that's it, I don't see this module loaded in list-modules in pacmd. > kde-settings-pulseaudio simply starts up pulseaudio -D, I take it that we > should do some extra configuration? That module is loaded from XDG autostart in /etc/xdg/autostart/pulseaudio-module-xsmp.desktop. We do this because we otherwise lock up when called as "esd" from gnome-session (because g-s waits for us to start up completely and doesn't handle s-m requests while sleeping and we thus cannot load the xsmp module immediately from default.pa, because that includes waiting for the s-m to respond, and there we got our dead lock) It's a dirty work around for the way things are with g-s right now. I know that the KDE people know about this, I have no idea how or if they fixed this for KDE. This XDG file should be interpreted by KDE too, but I am not sure about the order in which it is interpreted. KDE packagers, what do you say about this? > > If you trigger one of those CPU overload issues, than this is most > > likely due to the software entering some kind of busy loop. If you > > want to fix this, you need to find out why we enter this busy > > loop. Apparently the operation that should normally sleep for IO > > doesn't sleep for IO in this case. Usually this means that an IO > > condition that was signalled earlier was not handled as it should and > > thus not reset. Unfortunately bugs like this don't leave any useful > > coredumps, error messages or back traces and so can only be fixed by > > spending some time in gdb to figure out what happens. > > This is hard to debug indeed. :-( So I take it you have no idea where to start > with that? Hmm, install debuginfo packages. Run arts on top of PA through a profile when this happens. If done properly it gives you an idea of the hot spots, i.e. the loops that turned into busy loops. But in the end you need to run the whole mess in gdb, and step through the code and find out why one of the loops started to run amok. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
