On Wed, 2007-03-21 at 21:52 +1030, Arthur Marsh wrote: > > >>>>>> Running xmms under strace would prevent the problem from occuring. > > > > Didn't notice this before, so it could be timing related... > > > > > >> I started up the X server with old libx11-6, upgraded to libx11-6 > >> 1.1.1-1, then ran xmms and repeated the lock-up. > >> > >> I rebooted, set "accel" "off" in /etc/X11/xorg.conf in the section for > >> the video card in maintenance mode, then started X, ran xmms and > >> repeated the lock-up. > >> > >> I rebooted, set the driver from "cirrus" to "vesa", started X, ran xmms > >> and repeated the lock-up. > >> > >> I have downgraded the libx11-6, started X and xmms and was unable to > >> repeat the lock-up. > > > > Thanks for conducting these tests. Hmm, do you run xmms as root or > > normal user? It's hard to imagine how libX11 could cause the symptoms > > you describe in the latter case... > > I run xmms setuid root combined with the realtime-lsm kernel module to > give xmms real-time priority (still not skip-proof when playing MP3 > files across the LAN but much better than as a normal process contending > with other activity). > > Selecting "play directory" from xmms in a directory with a large number > of media files (e.g. 450 MIDI files) causes a *temporary* lock-up (no > keyboard response or screen updates) whilst xmms looks at the large > number of files. The real-time priority that xmms uses is unfortunately > not restricted to what is needed for audio output.
So it's possible that xmms enters an infinite loop (possibly in libX11) which due to its realtime priority prevents everything else from running? Can you try what happens if you run it without realtime priority? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
