Created attachment 423324 [details] GDB backtrace of X-Server Description of problem: The X-Server gets stuck in an infinite loop. It appears to be the same problem as described in https://bugs.freedesktop.org/show_bug.cgi?id=28320 Attaching gdb to the X-Server unveils (see attachment backtrace.log), that the X-Server is calling drmIoctl with the requestcode 0x40086482. The infinite loop is in drmIoctl itself. Looking at the sourcecode of nouveau_bo_wait shows, that it should be DRM_NOUVEAU_GEM_CPU_PREP=0x42. I'm a little bit confused, that requestcode ends with 82, although the definition of DRM_NOUVEAU_GEM_CPU_PREP indicates, that it should be 42. dmesg shows "[drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2" I also attached the output of the program peek (http://0x04.net/~mwk/pgtest/) which i have seen in some other bugreports. Version-Release number of selected component (if applicable): cat /sys/module/nouveau/srcversion -> 117DEC6255413EEBAF88071 yum info -> 6.20100423git13c1043.fc13 How reproducible: Happens randomly, at least once a day. Looking a movie with VLC increases the chance. Steps to Reproduce: 1. Watch a movie with VLC. 2. 3. Actual results: X-Server stuck in an infinite loop Expected results: X-Server should work properly. Additional info:
Created attachment 423327 [details] dmesg output
Created attachment 423328 [details] peek output
Created attachment 423478 [details] kernel function trace The ftrace was produced with 'echo nouveau_* drm_* ttm_* > set_ftrace_filter' option. Seems that the nouveau kernel module hangs in an infinte loop in nouveau_fence_wait.
That " [mi] EQ overflowing" message is completely meaningless. Please, read http://marc.info/?l=fedora-devel-list&m=124101535025331&w=2 and then take a look at the disaster which happens when people start to file this message as a bug at bug 465884. The rest of your analysis is much more interesting. Passing to developers.
Same problem here. I've thought the problem was with firefox+adobe flash player (64 bits), but even without the flash plugin, the problem still exists. I'm running a Thinkpad T510i with the mesa-dri-drivers-experimental installed. Without this package the system also hangs. I have: 01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev a2) Another curious thing is that when the screen locks, if I press the caps lock button, the led doesn't turn on or off. However, if I press the powerbutton (which is configured to "ask what to do"), and waiting 60 seconds, the system sometimes starts to shutdown and powerdown (screen image is not updated. I know it's shutting down due to hard disk activity led, and the power off at the end). Brightness control stops working, and pressing Fn+F5 makes the hard drive led to blink. My conclusion is that the system is not completely dead, only the screen image and keyboard. I'll try next time to make a ssh connection from another PC to see if the system allows me to login.
*** This bug has been marked as a duplicate of bug 596330 ***