[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#415541: libx11-6: 1.1.1-1 causes complete screen lockup / freeze from xmms





Michel Dänzer wrote, On 21/03/07 20:30:
On Wed, 2007-03-21 at 14:41 +1030, Arthur Marsh wrote:
Michel Dänzer wrote, On 20/03/07 20:41:
On Tue, 2007-03-20 at 20:01 +1030, Arthur Marsh wrote:
Michel Dänzer wrote, On 20/03/07 17:34:
On Tue, 2007-03-20 at 14:15 +1030, Arthur Marsh wrote:
When running libx11-6 1.1.1-1 and xmms 1:1.2.10+20061101-1, attempting to change the file menu width or traverse directories in "play file" would cause a complete screen / filesystem lockup (machine was pingable from another location but file shares not available and all keyboard and mouse input was ignored).

So I presume logging in via ssh isn't possible either?

I'll have to try that (or maybe rig up an EIA-232 null-modem connection to another pc as a serial terminal).


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.

I have filed a bug report or 2 against xmms - maybe I should file something there about this lock-up situation.

Arthur.



Reply to: