Bug 474207

Created attachment 271417 [details]
contains xorg.conf, Xorg.0.log

>I already reported this to linux-bugs@exchange.nvidia.com, but they say it's a
>X.org problem.

I don't think so, but feel free to reopen if you can reproduce it when using the nv, fbdev or vesa driver.

I have same issue but with open X.org's RADEON driver.
X session freezes randomly after some time. Mouse arrow can be moved. 
Only thing that can help is cold reset or ssh from another machine and KILL of X server.

Created attachment 287964 [details]
xorg old log file after X freezes and cold reset

Seems that X freezes only when composite extensions are used.
When I switch off composite effects overflow does not occur.
I'm using my system for a few day now without composite effects and have no freezes of X.

I have the same problem with a Radeon Mobilty 9600, since the update to KDE 4.3 (Beta 1).

I have this problem here and it is easily reproducible.
I use recent xorg server from xorg repository; open-source nv driver and no compiz.
Any time I open .mp3 inside firefox the xserver is stuck and can't be restarted with Ctrl-Alt-Backspace. Only SysRq magic keys help reboot. I have had renamed ~/.mozilla/firefox/ before reproducing so no plugins affect it. It happens for any mp3 file as I tried to open the first one I googled.
That started to happen after I updated xserver to XOrg repository as I was told in https://bugzilla.novell.com/show_bug.cgi?id=496034. As I can remember the default repositiory version worked fine.
After reboot Xorg.0.log.old contains
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.

Created attachment 294107 [details]
xorg.log

Created attachment 294108 [details]
xorg.conf used to reproduce the hang

(In reply to comment #8)
> Created an attachment (id=294107) [details]
> xorg.log

(EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)

You're trying to use nv driver with NVIDIA driver installed. This can result in
all kind of weird effects. :-(

Should I remove nvidia drivers from system or are there any way to temporarily disable them?

Unfortunately you need to remove them.

Created attachment 294256 [details]
This is xorg.conf that works fine

I played a bit with xorg.conf and found configuration that works okay! But whenerver I uncomment Option "Dualhead on" and reboot, xserver hangs on opening any mp3 in firefox. I tried it three times. It is definitaly that line of config triggers the hang.
Also, switching between init 3 and 5 doesn't hang xserver if a good configuration was used to boot.
Binary drivers are removed. SaX configuration works fine.
I suppose the animation firefox shows while playing music files makes xserver to hang when it is in dualhead mode.

Created attachment 294257 [details]
Xorg.log

Although, this time it is not indicating "[mi] EQ overflowing..." error. Probably, it was overwritten.

# man nv
[...]
Option "Dualhead" "boolean"
       Enables simple VBE-based dual head mode.   This  sets  the  same
       resolution  on both outputs and lays them out side-by-side.  The
       screens will be panned together as one big metamode if the  vir-
       tual desktop is larger than both screens combined.

> I suppose the animation firefox shows while playing music files makes xserver
> to hang when it is in dualhead mode.

I would assume so. Unfortunately I have no idea what firefox is using to show this
kind of animation. My FireFox cannot play MP3 files at all. Probably you're using
some to me unknown mp3 plugin ...

I have found that firefox uses totem plugin to play mp3s. Indeed, standalone totem player without visualizations works fine but it hangs after turning visualization on.
I use proprietary codecs but I think it is not mp3 but visualizer and should happen with any music format. I'll try to reproduce it with .ogg files too.

Created attachment 294738 [details]
/proc/maps of totem

Here is a copy of /proc/maps of totem process. May be you will find it useful.

As I supposed, Totem hangs xserver when playing .ogg files. Obviously it is not a music format problem but a kaleidoscope visualization.

Created attachment 295417 [details]
/proc/xxx/maps of totem process

https://bugs.freedesktop.org/show_bug.cgi?id=13987

This is the exactly what I have with my 7300LE

I have the same problem using the radeonhd driver with X600 (RV370) PCIE 5B62 card, it has only started since moving to KDE 4.2.x, however I switched from the proprietary ATI fglrx driver at the same time.

For me, the lockup happens on a variety of everyday activities, such as browsing using Konqueror and using OpenOffice, I have to ssh in and kill X to recover as
virtual consoles do not work either.

This infinite loop seems to affect many distributions and X drivers, so perhaps it is just a general error message being hit by many triggers (sifting problems would be a lot easier if there were timestamps in .xsession-errors and Xorg.0.log, as per other system logs).

There's a note in 
http://bugs.freedesktop.org/show_bug.cgi?id=19874 which looked promising, pointing to a few line fix in https://bugs.freedesktop.org/show_bug.cgi?id=13987,
but various other entries suggest my card isn't supported anyway!

X600(RV370) is not supported by radeonhd driver, so you likely are using radeon driver.

> This infinite loop seems to affect many distributions and X drivers, so perhaps
> it is just a general error message being hit by many triggers (sifting problems
> would be a lot easier if there were timestamps in .xsession-errors and
> Xorg.0.log, as per other system logs).

I agree.

> There's a note in 
> http://bugs.freedesktop.org/show_bug.cgi?id=19874 which looked promising,
> pointing to a few line fix in
> https://bugs.freedesktop.org/show_bug.cgi?id=13987,
> but various other entries suggest my card isn't supported anyway!

The patch only affects M82, when using radeon driver, but on openSUSE we're using
radeonhd driver for these by default. Also none of the affected persons here is
using a M82. So this won't fix that issue.

My mistake, I was using the radeon driver. 

I tried updating to xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-7.20
and saw the problem less frequently, but it was still there. However, I suspect that this is being triggered from the compositing within KDE4.2 and
there have been regular updates, so the whole mix of conditions is changing.

I saw the same problem this morning on my laptop, which has an Intel 855GM and
similarly runs openSUSE 11.1 with KDE4.2.x. X is using the intel driver.

I am also seeing this on my laptop.  I have Intel 945GM graphics card on my laptop, using the i915 intel driver in X.  This has happened when running KDE 4.2.x both with and without desktop effects.

List of RPM package names and versions, when I experienced this latest incident:
xorg-x11-7.4-8.19.1
xorg-x11-driver-video-7.4-19.8.2
KDE 4.2.4     (from KDE:KDE42 repo)

I updated to KDE 4.3 using the Factory repo for Opensuse 11.1, and everything has OK now for 3 weeks now, even with composite enabled in KWin.  Don't know if KDE 4.2.X was the root cause of this, but it is looking that way.

Valur - thanks! I upgraded to KDE 4.3 at the beginning of the week on my desktop (ATI X600 with radeon driver) and haven't had this bug since (I was hitting it 2-3 times each day and it was driving me up the wall). I'm still
using compositing and haven't changed any other settings.

I was a bit hesitant to try out 4.3, in case it was unstable, but apart from kded4 needing a kill -9 to stop it hogging a core after the first run, things have been very stable. I've had the odd SEGV from Konqueror & akregator, but just as much as with 4.2. On balance, I'd rather an application die than the whole of X lock, but the apps haven't died.

I'm not sure if there is anything to do here still. This problem occurs when there are too many input events queued while the Xserver is still blocked on waiting for the engine to finish rendering. Input is dealt with in a signal handler while the main loop cannot process the queued events.
It's not unlikely that some application flooding X with huge rendering tasks is causing this.
This bug seemed to have been cross hardware, thus it's unlikely a driver/hardware issue that's causing the engine to lock up.
Also I cannot reproduce it any more.