Description of problem: Playing any video format (mpg, mp4, flv, I think), with kaffeine, kplayer, kmplayer, dragon player, etc locks up X (mouse pointer and keyboard still work, but, as control-alt-backspace are disabled, only magic sysrq is possible). Version-Release number of selected component (if applicable): xorg-x11-drv-intel-2.7.0-2.fc11.x86_64 How reproducible: Try to play a video file. Disabling desktop effects has no impact on the problem. Steps to Reproduce: 1. Either click on a file in dolphin or open the program and select open file. 2. The video will play for a second, then it freezes or goes blank (sometimes black), while sound might continue for a few seconds, then X freezes and no user action can get out of the problem, save alt-sysrq. 3. Actual results: Frozen screen and no video playback possible. Expected results: It should be possible to play video files. Additional info: When viewing video within firefox, using adobe experimental 64-bit flash player, all is fine.
I just finished watching, with great trepidation, a video using Gnome Mplayer. It played for over 50 minutes, but I didn't dare change the size of the window. At the end, as the credits were rolling, I slowly dragged the frame to enlarge it. At first, it seemed to work fine, then, as I managed to achieve a significantly larger size, it froze, just like all the other programs had. I could do nothing and was forced to reisub.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Is the computer really frozen as whole, or just X? Are you able to connect to the “frozen” computer with ssh? Give it five minutes or so, whether something won't timeout, and computer defrosts itself. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 341366 [details] Xorg.0.log
There is no xorg.conf, as is it is no longer required. I have no idea whether I could connect to the 'frozen' computer. I guess I could try later on, using my laptop (my guess is that only X is frozen, as I can still issue the magic sysrq and the mouse pointer still moves, but I cannot move to another virtual terminal). Yes, next time, I will give it longer than a minute or two, to see if it 'defrosts' itself. I know that I waited a while on a few occasions, but definitely not that long.
I just successfully logged in to the frozen desktop (x86_64) computer using the laptop (i686, uses kernel-PAE). I transferred a file, to make sure. Then, I tried to replicate the problem on the laptop, but I could not. I played various video files, dragged the windows around the screen and stretched them open wider, etc. Nothing happened, except that the playback got garbled, but I was able to press pause and pause again and playback resumed normally. After a time, kde automatically disabled desktop effects, claiming that the graphic card was too slow, but giving me the option to re-enable it, should I so desire. The laptop has Intel Mobile 915GM/GMS/910GML Express. The desktop has INTEL X3000 (Chipset 965G). I left the frozen desktop computer on for at least 10 minutes, but it never unlocked during the elapsed time. I had to resort to the magic sysrq to break out of it. I should also note that the desktop uses kernel-based mode setting. The laptop computer does not. I have nomodest on the kernel boot line, because when I use modesetting with the laptop, all I get is a black screen and I am unable to change to another virtual terminal, even though I think the computer is running (I have not tried ssh to confirm, nor do I know whether ssh would work when I am not yet logged in, but at kdm). Refer to bug https://bugzilla.redhat.com/show_bug.cgi?id=488824.
*** This bug has been marked as a duplicate of bug 496614 ***