[nvidia-glx] 3D GL apps crash X when using compiz due to unmaked ABI change (gutsy)

Can confirm it here too on x86_64 w/ intel_agp disabled

Correction- intel_agp was not blacklisted the last time I tried it, disabled it like it was when still using a 32 bit kernel w/ PAE, no effect.

(II) NVIDIA(0): Setting mode "1400x1050"
(II) Configured Mouse: ps2EnableDataReporting: succeeded
SetClientVersion: 0 9
SetClientVersion: 0 9

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6d) [0x4858ad]
1: /lib/libc.so.6 [0x2b1412f57760]
2: /lib/libc.so.6(cfree+0x3b) [0x2b1412f9b5fb]
3: /usr/lib/xorg/modules/drivers//nvidia_drv.so(_nv002196X+0x1f7) [0x2b14158df037]

Fatal server error:
Caught signal 11. Server aborting

Still crashes w/ nVidia driver 100.14.11 installed from nvidia site.

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6d) [0x4858ad]
1: /lib/libc.so.6 [0x2af428df0760]
2: /lib/libc.so.6(cfree+0x3b) [0x2af428e345fb]
3: /usr/lib/xorg/modules/drivers//nvidia_drv.so(_nv002411X+0x1f6) [0x2af42b8a4e86]

Fatal server error:
Caught signal 11. Server aborting

Probably should be merged w/ bug #130914

John:
As you have reproduced this issue with drivers direct from NVIDIA, it is probably worth reporting this to NVIDIA via http://www.nvnews.net/vbulletin/forumdisplay.php?f=14 if they can tell you where the problem lies.

It's not a nvidia issue really, as using the same version across Feisty and gutsy produce very different results (Feisty works, Gutsy doesn't) So let's dispell that idea now. It's either X itself in some way, or compiz. Most realistically I would say X in some form.

Bryan:
It could well be incompatibility between the newest xorg and the NVIDIA drivers. As the backtrace includes an NVIDIA driver binary function the folks who are in the best position to answer this are NVIDIA as they will be able to say "yes it's xorg doing something wrong right here" or "it is a bug in our drivers". I doubt the problem lies with Ubuntu's packaging of the NVIDIA drivers because John clearly stated he has tested the binary from the NVIDIA site too (of course I am assuming that John was really running that driver).

To put it bluntly there's no way this can be compiz as compiz is a userland app and thus only "talks" to the X server. This is either a bug in xorg or the NVIDIA binary drivers (or the compiler miscompiling something or the etc) and unless you can tell me what is happening in the the function _nv002196X+0x1f7 along with what was happening in the run up to that function I suspect you will struggle to narrow this down...

Same bug for me!

My system: actual Gutsy (i386), Dell Inspiron 6400 with nvidia GeForce Go 7300 and nvidia-glx-new driver.

With enabled compiz, X crashes and GDM restarts when I open 3-D-apps like glxgears or 3-d games like second life.

No problems when I disabled desktop-effects!

Never had this bug with Feisty and compiz from Trevinos repos.

Sitsofe:
Yea, I meant to cover most of that. That's why I was saying it was most realistically not a Compiz problem, that wouldn't make a ton of sense for it to be. And I'm in the same position, testing across multiple nvidia versions (compatible with the environment of feisty entirely) so that can all but alleviate any thoughts that it might be trouble with the nvidia binary and pretty much throws it to something happening differently in X or in that ballpark. Obviously somehow having to do with rendering opengl separately as compiz is flying. It might ven be an issue of either the resolution of the render (which is odd, not entirely off the hat though), or a matter of how much it renders (which would in part tie in to part a there). I say this becuase it seems smaller render jobs, windowed things even, work to some degree for many people. For me I can play a windowed wine game for the most part fine, where as mythfrontend crashes X, assuming the full 3d game in a window takes more actual rendering I'm leaning towards the weird but not implausible that it's in relation to rendering size (this same game crashing in fullscreen mode.)

Same issue.

All opengl apps crash. Including multiple-texture-opengl video-output in mplayer. Opengl screensavers, glxgears, games. They all make it crash.

However, it does not happen when:
  - running metacity instead of compiz

In the past running games with compiz was slow.
Running games with beryl was fast.

Is there still a beryl repo for gutsy somewhere?
This could tell us if compiz is the culprit or not.

In my case I have to blame the installer. I had the same back trace like the very first one in this thread (obviously except for memory addresses). I had an upgraded Kubuntu gutsy environment from a feisty installation with all the updates applied. But this problem started very recently with an update which upgrade xserver-xorg to 7.2-5ubuntu6.

After trying different things for couple of times I decided to reinstall my OS from the latest gutsy CD image which is "Gutsy Gibbon Tribe 4". Luckily I have my /home and /opt in different partitions and hence I can format my root partition. After the installation I applied the updates and now my system works fine.

So I think its some installer problem which may have left an old library lying around.

That is interesting Sanjaya!

My system is an updated one, too! Maybe i try a fresh installation, too. Thanks for that hint.

On the other hand, we should find out, which library is the bad-boy. An update from Feisty to Gutsy should go smooth, too.

So, glxgears now works for you, Sanjaya, with compiz enabled ?

I installed tribe 2 and updated ever since.
Question 2: games are fast now as well with compiz enabled ?

It was always fast with Beryl, but with compiz opengl apps and games were so slow.
And now they don't work..

I am not running Ubuntu, but I am running Debian, from which Ubuntu hath been spawned. I have the same-ish problem.

I found this forum about it:
http://www.debianforum.de/forum/viewtopic.php?t=87095&sid=6cd9375a38649ebcf06bb81e04a86e23

The theoretical *fix* for this:

put this in your device section for the NVIDIA driver of xorg.conf:

    Option "NvAGP" "1"

...
There are several choices for configuring the NVIDIA kernel module's use of
AGP on Linux. You can choose to either use the NVIDIA builtin AGP driver
(NvAGP), or the AGP driver that comes with the Linux kernel (AGPGART). This is
controlled through the "NvAGP" option in your X config file:

    Option "NvAGP" "0" ... disables AGP support
    Option "NvAGP" "1" ... use NvAGP, if possible
    Option "NvAGP" "2" ... use AGPGART, if possible
    Option "NvAGP" "3" ... try AGPGART; if that fails, try NvAGP

The default is 3 (the default was 1 until after 1.0-1251).
...

I have not actually tested this yet, I will wait until my boxes crashes again :-P

>> So, glxgears now works for you, Sanjaya, with compiz enabled ?

Well, I couldn't get any OpenGL stuff running earlier and now they are working (OpenGL screen servers, OpenGL programs I have written, etc). I haven't use compiz since I am on Kubuntu and didn't want to load the gnome stuff.

I can give it a try and let you all know.

Same here. Most opengl stuff works now. But games are still very slow and do not work when 'use legacy fullscreen redirection thingie' is on in the workarounds-plugin.

- GlxGears still makes it crash.
- performance of full-screen 3d games is still terrible. Just terrible. It was perfect with Beryl, what's going on?

I've tried the NvAGP with 0,1,2,3

It's something else that:
  - makes glxgears crash
  - make 3d games unplayable with compiz-fusion

I'm not having it crash anymore when I try a 3d application, but I've lost window decorations when desktop effects are enabled.

Ugh.

The NvAGP idea was no go, though I expected little from that.

--
Cheers,
Bryan

Same bug here with a toshiba laptop qosmio G20.

I m running nvidia 9631 installed by gutsy tribe 5 up to date.

Beryl and compiz do work but running glxgears makes X crash (going back to gdm).

It s a gutsy issue since running on feisty the same driver is ok.

I tried the idea of nvagp to 1 but it has no effect on my laptop.

This is what I am experiencing with the latest updates in Kubuntu. I have translucency enable which again make use of OpenGL functionality I believe. glxgears works fine and other OpenGL applications. I didn't try any games since I am not much in to that. I tried installing compiz for KDE. glxgears window comes with a blank (black) area, meaning I don't see the gears. But X doesn't crash.

I've just re-installed Ubuntu from herd 5, this time using the 64-bits version.
GLXGears does not crash with compiz-fusion enabled when using the 64-bits version of Ubuntu.

It's just getting more confusing.

Same problem here with NVIDIA geforce 7200 go....and nvidia-glx-new driver....
with compiz fusion enabled...google earth crashes X...even games and several gnome screensavers crash X.

Did anybody find any solution?

I strongly recommend asking NVIDIA for help with this issue using their forum on http://www.nvnews.net/vbulletin/forumdisplay.php?f=14. If you are thinking of doing this you will HAVE to manually install their official binary package (see https://help.ubuntu.com/community/NvidiaManual for potential gotchas and a brief guide) and you MUST heed the steps in http://www.nvnews.net/vbulletin/showthread.php?t=46678 . NVIDIA employees will probably not look at issues that do not meet their guidelines.

If NVIDIA do investigate your problem please post a link to the forum thread within a comment here.

If it is a NVIDIA problem, then why doesn't it appear in a fresh installation of Feisty with the same NVIDIA drivers ?

So I don't understand why i should post in NVIDIA forums.

I had the same glx-crahses described above even without compiz.
My solution (for i386 and for amd64 architecture) was to supress AIGLX (from Xorg 7.1 I think) and allow the Nvidia driver to use it's own NV-GLX:

$ grep -i glx /var/log/Xorg.0.log
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="NVIDIA Corporation"
(II) NVIDIA GLX Module 100.14.11 Wed Jun 13 18:58:58 PDT 2007
(II) Loading extension GLX
(II) NVIDIA(0): Support for GLX with the Damage and Composite X extensions is
(==) NVIDIA(0): Disabling 32-bit ARGB GLX visuals.
(II) Loading extension NV-GLX
(II) Initializing extension GLX

I am not sure which xorg.conf option is the crucial one, running
NVIDIA-Linux-x86-100.14.11-pkg1.run resp. NVIDIA-Linux-x86_64-100.14.11-pkg2.run did something.
I attach my xorg.conf (Gutsy i386, all updates), however it could be the crucial step is somewhere else.

(Subscribing Cyrilou. If you are asking questions in bug reports please subscribe to the bug so that other people have a means to reply)

Cyrilou.
Please see https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/130325/comments/7 .

Same here.
Tested with metacity, no problems. With compiz-fusion, X restarts.
Using an GeForce 8800GTS under gutsy with official newest NVidia binary drivers (because of another dumb bug with the nvidia-glx-new package not containing a needed file for the 8xxx set of cards).

same here

I also got bit by this bug when I upgraded to tribe 5 Gutsy. Prior to that I was running Beryl with glx programs and all was well. After the upgrade, the Beryl version (which I had previously compiled from source code I grabbed from subversion repositories) was also problematic. The cube rotation worked, but window decorations crashed.

I uninstalled my Beryl installation and installed Gutsy's Compiz. After some fooling around, I got everything to work, except it crashes the Xserver when I run glxgears or anything else like that. None of the above suggestions helped.

I uninstalled Compiz-fusion and recompiled Beryl (same source code I still had available) and basically it works fine except for the glx problem that Compiz had.

So I think this is a reasonable control, and I am more inclined to believe it is Xorg and/or the Nvidia driver I have that Compiz or Beryl per se.

Confirmed with Gutsy Tribe-5 64-bit.

I should have said that my guess is that this issue is a problem in one or more of Xorg/kernel/NVIDIA binary driver. You will probably need NVIDIA's help to find out where the issue actually is though (it could be due to a subtle change in how things need to be called or the uncovering of a real bug due to new functionality or changes). If NVIDIA are able to follow someone's steps to reliably reproduce this problem themselves then I suspect they will quickly pinpoint where the issue lies.

It's very easy to reproduce:

1. Upgrade to Gutsy and (re)install the latest nvidia drivers.
2. Install the distributed compiz-fusion
3. Run glxgears

FWIW I have heard of this happening on FC since at least January of this year.

I got some backtraces. They are slightly different depending on whether glxgears is run first or compiz. I reported the problem to linux-bugs(at)nvidia.com and hope they will come back to us:

$ glxgears
$ compiz
(gdb) symbol-file /usr/lib/debug/usr/bin/Xorg
(gdb) where
#0 0xb7db97cc in free () from /lib/tls/i686/cmov/libc.so.6
#1 0x081c3281 in Xfree (ptr=0xfffffffb) at ../../os/utils.c:1471
#2 0xb7216b06 in _nv002179X ()
   from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#3 0x00000003 in ?? ()
#4 0xb7217744 in ?? () from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#5 0xbf921e88 in ?? ()
#6 0x00000000 in ?? ()

$ compiz
$ gtk-window-decorator
$ glxgears
(gdb) where
#0 0xb726e98a in _nv001744X ()
   from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#1 0xb726da34 in ?? () from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#2 0x764b1210 in ?? ()
#3 0xb6370010 in ?? ()
#4 0x08215950 in ?? ()
#5 0x084fba78 in ?? ()
#6 0x084f05e8 in ?? ()
#7 0xb6370010 in ?? ()
#8 0x08215950 in ?? ()
#9 0x08205538 in ?? ()
#10 0x00000000 in ?? ()

$ compiz
$ glxgears
Program received signal SIGSEGV, Segmentation fault.
0xb71e90f0 in _nv002762X () from /usr/lib/xorg/modules/drivers//nvidia_drv.so
(gdb) where
#0 0xb71e90f0 in _nv002762X ()
   from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#1 0xb71dcfdc in _nv002301X ()
   from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#2 0xb69fd008 in ?? ()
#3 0xbfcbd09c in ?? ()
#4 0x00000003 in ?? ()
#5 0x00000000 in ?? ()

Some more backtrace with 100.14.11:

$ compiz
$ glxgears
$ glxgears
(gdb) where
#0 0xb7d637cc in free () from /lib/tls/i686/cmov/libc.so.6
#1 0x081c3281 in Xfree (ptr=0x9) at ../../os/utils.c:1471
#2 0xb709a66f in _nv002390X ()
   from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#3 0x00000011 in ?? ()
#4 0x00000000 in ?? ()

$ glxgears
$ compiz
(gdb) where
#0 0xb7e1c7cc in free () from /lib/tls/i686/cmov/libc.so.6
#1 0x081c3281 in Xfree (ptr=0xfffffffb) at ../../os/utils.c:1471
#2 0xb7153416 in _nv002388X ()
   from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#3 0x00000003 in ?? ()
#4 0xb71542d0 in ?? () from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#5 0xbf98f6f8 in ?? ()
#6 0xb71c64c5 in ?? () from /usr/lib/xorg/modules/drivers//nvidia_drv.so
#7 0xbf98f780 in ?? ()
#8 0x083d7fe8 in ?? ()
#9 0x00000001 in ?? ()
#10 0xbf98f788 in ?? ()
#11 0xcafe0009 in ?? ()
#12 0x00000000 in ?? ()

Here is another update. I managed to build xserver-xorg with a minimum amount of patches (basicly just debian/patches/125-127) and after installing that and installing the 100.14.11 nvidia driver it does no longer crash. So it seems like on of our patches breaks nvidia.

It is worth pointing out that my initial thoughts on what would be the quickest thing to do were wrong. Michael has shown that an alternative way to have tracked down the issue was to recompile xorg without any patches and assuming that works then you can use repeated bisection and recompiles to narrow down the issue. If you can do this then there's no need to initially contact NVIDIA as you can narrow the issue down to a single patch (but you would need to talk to a xorg person or NVIDIA to find out whether the patch was bogus).

I've noticed the following in the changelog for the latest xorg (2:1.3.0.0.dfsg-12ubuntu3) mentions the following:
- 230_In___glXCreateARGBConfig_insert_the_new_GL_mode_at_the__end__of_the_linked_list.patch:
      Fixes insertion order of linked list that can cause GLX clients to fail when attempting to use the last GLX mode/visual.

There is a chance the latest xorg update (presumably 2:1.3.0.0.dfsg-12ubuntu3) may solve this issue. Can someone install it, restart X and report back?

I'll do that tomorrow, if nobody beats me to it before.

Nope. Still borked.

ii xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu3 X.Org X server -- core server

I'll try re-compiling bery just in case...

On Wed, 05 Sep 2007 21:49:45 -0000
Sitsofe Wheeler <email address hidden> wrote:

     There is a chance the latest xorg update (presumably 2:1.3.0.0.dfsg-
     12ubuntu3) may solve this issue. Can someone install it, restart X and
     report back?

Agreed, still broken.

I should add recompiling the svn of Beryl I grabbed a few months ago (i.e., on that used to work) made no difference.

On Sat, Sep 15, 2007 at 12:02:12AM -0000, Duncan Lithgow wrote:
> I've also just tried this and have the same behaviour as 3vi1 on a
> GeForce Go 7400

Did the linked (above) xorg-server package not fix it for you?

I will try the xorg-server package is someone can tell me how to revert to the ubuntu package from the command line if it breaks Xorg. Happy to help, but not at too much risk... :)

It depends how you install it.

Install Method A: adding his repo to your sources.list
1. You can add the ppa to your sources.list (bit overkill)
2. Update to that xserver using update-manager

Remove Method A:
1. type sudo nano /etc/apt/sources.list
2. delete the line containing his ppa-repo
3. Control+O to save
4. type aptitude update
5. type aptitude clear
6. type aptitude reinstall xserver-xorg
7. DONE

If you just directly install the .deb file with gdebi you can remove it by starting at point 4.
You don't need to remove the repo in that case, just clear the cache!

You can also likely do something like:
sudo aptitude install xserver-xorg/gutsy

You can also just launch aptitude and do in the text-gui of aptitude (which is much like synaptic)
You should be able to revert to another version there.

@duncan

i'm not entirely sure what the correct settings should be
I think we all experiment with the settings when it didn't work.
I wonder what the actual defaults of restricted-manager are ..

unsucbscribe

unsubscribe

On 9/15/07, Ralf Nieuwenhuijsen <email address hidden> wrote:
>
> @duncan
>
> i'm not entirely sure what the correct settings should be
> I think we all experiment with the settings when it didn't work.
> I wonder what the actual defaults of restricted-manager are ..
>
> --
> [nvidia-glx] 3D GL apps crash X when using compiz due to unmaked ABI
> change (gutsy)
> https://bugs.launchpad.net/bugs/130325
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Cook's xserver-xorg-core package seems to fix the issue for me. At least, glxgears no longer makes X crash, nor does playing a video fullscreen in mplayer. These two thing caused crashes 99.9% of the time previously.

My only disappointment was that it did not fix an issue I had thought might be related but now turns out not to be: The bug where if you have multiple tabs open in yakuake and the first (hidden) one is scrolling text (ex. compiling), and you minimize yakuake, X will crash/restart. Oh well.

I think Kees' fix is probably the best way to go for everyone involved. Patches probably shouldn't reorder these structures in the first place if it needlessly breaks binary compatibility with the video drivers. That kind of change should be reserved for larger X revisions.

On Sat, Sep 15, 2007 at 10:02:16AM -0000, Duncan Lithgow wrote:
> I will try the xorg-server package is someone can tell me how to revert
> to the ubuntu package from the command line if it breaks Xorg. Happy to
> help, but not at too much risk... :)

If you need to revert, you can use:

sudo apt-get install xserver-xorg-core=2:1.3.0.0.dfsg-12ubuntu4

You can check the available versions in the repositories with:
  apt-cache madison xserver-xorg-core

--
Kees Cook @outflux.net

unsubscribe

Trying to install:
xserver-xorg-core-dbg_1.3.0.0.dfsg-12ubuntu5~ppa1_i386.deb

I get:

Package: xserver-xorg-core
Error: Dependency is not satisfiable: xserver-xorg-core

But of course xserver-xorg-core is already installed! So what's up.

Okay, so installing xserver-xorg-core-dbg was dumb. Now I've tried xserver-xorg-core and I'm in real trouble. It lost the screen resolution and keymap setting (dk). I reinstalled the original xserver-xorg-core package and put X11's backup (xorg.conf.broken) back in place as xorg.conf. I still have a resolution of 640xsomething and a broken keymap. Can someone help me re run the original config script to make my desktop usable again? Attached is my current xorf.conf file.

You used the Bulletproof X Xorg.conf... not a bright idea =]
sudo dpkg-reconfigure xserver-xorg

Duncan Lithgow wrote:
> Okay, so installing xserver-xorg-core-dbg was dumb. Now I've tried
> xserver-xorg-core and I'm in real trouble. It lost the screen resolution
> and keymap setting (dk). I reinstalled the original xserver-xorg-core
> package and put X11's backup (xorg.conf.broken) back in place as
> xorg.conf. I still have a resolution of 640xsomething and a broken
> keymap. Can someone help me re run the original config script to make my
> desktop usable again? Attached is my current xorf.conf file.
>
> ** Attachment added: "xorg.conf"
> http://launchpadlibrarian.net/9293530/xorg.conf
>
>

I'm an experienced user (Linux since 1993, Minix before that), but I lost several hours before I realized that glxgears and FlightGear were crashing X due to compiz. I *strongly* recommend disabling compiz by default in gutsy, since it provides nothing but eye candy, and having it running means that 3D apps will crash X by default in gutsy for all boxes running new NVIDIA cards -- it's easy enough to enable in the GUI for people who want it. Functionality should always win over flash.

Even when I'm not trying to run 3D apps, compiz seems very awkward on my new HP TX1220 compared with metacity -- there are sometimes freezes of several seconds, for example, especially when I'm trying to edit in OpenOffice. It may be cute, but it's not practical.

"Functionality should always win over flash." +1
If we want to stop Compiz being turned on by default we need to make some noise. I see no sign that Canonical is watching this thread with interest.

Regarding my comment above: I'm not sure that the repackaged Xorg had anything to do with the strange behaviour I was seeing, and all is running fine again. Oh except, that it's still broken, as we all know.

I'm also an experienced user with the same problems. Are these problems difficult to identify because we don't have the driver source code? Either way, the desktop effects are not stable with the current nVidia drivers so unless that gets resolved soon, I think that enabling them by default is not very wise.

Well personally I've enabled the package popularity contest
( sudo dpkg-reconfigure popularity-contest )

and uninstalled compiz completely (the dependencies still
let you for now) *maybe* someone looks at the stats
and *maybe* enough people will get sick of eye candy
killing xwindows and uninstall compiz

Over the last year Vista has been doing Ubuntu lots of favours
I guess in November its going to be Ubuntu's turn to pay the
favour back....

Richard Ayotte wrote:
> I'm also an experienced user with the same problems. Are these problems
> difficult to identify because we don't have the driver source code?
> Either way, the desktop effects are not stable with the current nVidia
> drivers so unless that gets resolved soon, I think that enabling them by
> default is not very wise.
>
>

It's not compiz. It's the nvidia-driver that is messing up. It just shows because of compiz actually uses lots of those functions.

Please read all the comments above about the cause.

In other words:
  - the closed-sourced driver is to blame (this is where the bugs are)
  - the closed-sourced driver is not installed by default
  - there will likely be a xserver patch that solves the major problems (by using a workaround)

More specically .. there are two unrelated issues:
  issue 1: nvidia does not support more than one xserver session per gpu (this makes switching users break)
  issue 2: nvidia's driver and our xserver abi's are out of sync

Issue 2 is not related to compiz. It will likely be solved by a workaround in the xserver (note that it requires no change in compiz). These sort of issues are common with closed-source drivers.

Issue 1 is not related to compiz, but related to nvidia's lack to support (or care about) running more than one xserver on your computer. These sort of issues are common with closed-source drivers. We can't fit it and they don't care. They said: "that's not a supported configuration"

In other words: this does not concerns bugs in Compiz

These unrelated problems may happen to you, but things like freezing out
temporarily don't happen to everyone.. Your own logic can be turned
around.. Those who don't want it can easily turn it off =] This problem
will be fixed with the next nvidia release which will most assuredly
have to be passed back in to gutsy, even if hardy work has started.

David Megginson wrote:
> I'm an experienced user (Linux since 1993, Minix before that), but I
> lost several hours before I realized that glxgears and FlightGear were
> crashing X due to compiz. I *strongly* recommend disabling compiz by
> default in gutsy, since it provides nothing but eye candy, and having it
> running means that 3D apps will crash X by default in gutsy for all
> boxes running new NVIDIA cards -- it's easy enough to enable in the GUI
> for people who want it. Functionality should always win over flash.
>
> Even when I'm not trying to run 3D apps, compiz seems very awkward on my
> new HP TX1220 compared with metacity -- there are sometimes freezes of
> several seconds, for example, especially when I'm trying to edit in
> OpenOffice. It may be cute, but it's not practical.
>
>

That's not how it works. This bug will cause loss of work and data to a large part of the userbase, which may have no clue that this can happen, why it happens or how to work around it. At the same time, those who think it is really important to have bling will find and turn this feature on. I've never understood why a vocal minority that will enable this manually anyways thinks it's so important that everyone else must have their pet feature forced on them by default?

I'm all for composite being the default once it is stable and polished (not worse than metacity, which it is in many cases right now even though it is better in other parts).

Doesn't really matter if this is a closed source issue, people will lose work and data if this goes out by default as it is now. Is that worth it so some other people can have a fireworks show? Really?

On 17/09/2007, Bryan Haskins <email address hidden> wrote:

> These unrelated problems may happen to you, but things like freezing out
> temporarily don't happen to everyone.. Your own logic can be turned
> around.. Those who don't want it can easily turn it off =] This problem
> will be fixed with the next nvidia release which will most assuredly
> have to be passed back in to gutsy, even if hardy work has started.

Reversing the logic doesn't work, because in one configuration, gutsy
will won't work out of the box for a lot of people, while in the
second configuration, it will. Why not wait until there are fixed
nvidia drivers in gutsy to make compiz the default? BTW, search for
"compiz freeze" to find people with the other problem -- you don't
need *everyone* to be having the problem, just a significant number,
for Ubuntu to start losing its excellent reputation as the distro that
actually works out of the box.

Stacked up against all this, what real benefits do we get from forcing
compiz in before the distro is stable with it? Cute window
animations?

All the best,

David

Nah most users just disable it rather than uninstall it, as with all of
the base system.
ChrisC wrote:
> Well personally I've enabled the package popularity contest
> ( sudo dpkg-reconfigure popularity-contest )
>
> and uninstalled compiz completely (the dependencies still
> let you for now) *maybe* someone looks at the stats
> and *maybe* enough people will get sick of eye candy
> killing xwindows and uninstall compiz
>
> Over the last year Vista has been doing Ubuntu lots of favours
> I guess in November its going to be Ubuntu's turn to pay the
> favour back....
>
>
> Richard Ayotte wrote:
>
>> I'm also an experienced user with the same problems. Are these problems
>> difficult to identify because we don't have the driver source code?
>> Either way, the desktop effects are not stable with the current nVidia
>> drivers so unless that gets resolved soon, I think that enabling them by
>> default is not very wise.
>>
>>
>>
>
>

This is getting rather off topic, this is not a discussion about Compiz
Fusion by default, this is a discussion about this issue, and solutions
to it. While I would agree it's not outside the scope to talk a bit
about how this effects us with compiz by default, your voice will not be
heard by the right people here.

Kristoffer Lundén wrote:
> That's not how it works. This bug will cause loss of work and data to a
> large part of the userbase, which may have no clue that this can happen,
> why it happens or how to work around it. At the same time, those who
> think it is really important to have bling will find and turn this
> feature on. I've never understood why a vocal minority that will enable
> this manually anyways thinks it's so important that everyone else must
> have their pet feature forced on them by default?
>
> I'm all for composite being the default once it is stable and polished
> (not worse than metacity, which it is in many cases right now even
> though it is better in other parts).
>
> Doesn't really matter if this is a closed source issue, people will lose
> work and data if this goes out by default as it is now. Is that worth it
> so some other people can have a fireworks show? Really?
>
>

Again see my last reply there, but this again is straying off topic. My
understanding is that the system will actually be checked for proper
compatibility before all of this. Worst case, it tries to start up, X
dies, and restarts in Compatibility mode, Compiz is disabled, and all's
fine, but the regular check should catch most things, so no worries =]

David Megginson wrote:
> On 17/09/2007, Bryan Haskins <email address hidden> wrote:
>
>
>> These unrelated problems may happen to you, but things like freezing out
>> temporarily don't happen to everyone.. Your own logic can be turned
>> around.. Those who don't want it can easily turn it off =] This problem
>> will be fixed with the next nvidia release which will most assuredly
>> have to be passed back in to gutsy, even if hardy work has started.
>>
>
> Reversing the logic doesn't work, because in one configuration, gutsy
> will won't work out of the box for a lot of people, while in the
> second configuration, it will. Why not wait until there are fixed
> nvidia drivers in gutsy to make compiz the default? BTW, search for
> "compiz freeze" to find people with the other problem -- you don't
> need *everyone* to be having the problem, just a significant number,
> for Ubuntu to start losing its excellent reputation as the distro that
> actually works out of the box.
>
> Stacked up against all this, what real benefits do we get from forcing
> compiz in before the distro is stable with it? Cute window
> animations?
>
>
> All the best,
>
>
> David
>
>

Maybe I am missing the point ..

1) Compiz is not on by default for NVidia

But if you own an Nvidia card, then there is no compiz by default!
Why do people insist on claiming that there is?

You are M-A-N-U-A-L-L-Y installing an U-N-S-U-P-P-O-R-T-E-D driver.
After which compiz is enabled by default, because the driver _claims_ it supports 3d.
Unfortunately this driver is incompatible with the particular XServer of Gutsy, hence the driver crashes.
If this is not fixed before gutsy launch, i'm pretty sure nvidia will be on the blacklist and compiz will not be enabled for Nvidia users.

No freaking reason to disable compiz for Intel videocards, because Nvidia won't work. That makes no sense.

2) There is test package of xserver that FIXES those issues. If you bother to read the whole thread you would know that. You can test that package yourself. The more people that claim that it 'works' .. the more likely the patch will be included in gutsy.

When the patch is included in gutsy and it fixes the problem, then nvidia won't need to be blacklisted.

3) There are valid arguments against enabling compiz by default for anyone. But this aint one of them. This is nvidia-specific crashes, for which a working patch exists, that have got nothing to do with compiz.

Stop the FUD please.

Exactly =]

But it's unlikely the package will be taken in to gutsy, all it does
afaik is remove the patch with causes incompatibility, this patch is
needed for mobile devices, as said earlier in the bug chatter.
Technically it's not something we should work around. though for the
sake of a good user product... well it's complicated.

Essentially until nvidia updates you will see user rolled xorg packages
floating around, so in main we have the xorg which pressures, to
whatever level they choose to ignore, nvidia in to updating.

Is it a pita for new users? Totally. But in the end it will get the job
done, which is fixing the driver, not working around it to break other
things that we've developed.

Ralf Nieuwenhuijsen wrote:
> Maybe I am missing the point ..
>
> 1) Compiz is not on by default for NVidia
>
> But if you own an Nvidia card, then there is no compiz by default!
> Why do people insist on claiming that there is?
>
> You are M-A-N-U-A-L-L-Y installing an U-N-S-U-P-P-O-R-T-E-D driver.
> After which compiz is enabled by default, because the driver _claims_ it supports 3d.
> Unfortunately this driver is incompatible with the particular XServer of Gutsy, hence the driver crashes.
> If this is not fixed before gutsy launch, i'm pretty sure nvidia will be on the blacklist and compiz will not be enabled for Nvidia users.
>
> No freaking reason to disable compiz for Intel videocards, because
> Nvidia won't work. That makes no sense.
>
> 2) There is test package of xserver that FIXES those issues. If you
> bother to read the whole thread you would know that. You can test that
> package yourself. The more people that claim that it 'works' .. the more
> likely the patch will be included in gutsy.
>
> When the patch is included in gutsy and it fixes the problem, then
> nvidia won't need to be blacklisted.
>
> 3) There are valid arguments against enabling compiz by default for
> anyone. But this aint one of them. This is nvidia-specific crashes, for
> which a working patch exists, that have got nothing to do with compiz.
>
> Stop the FUD please.
>
>

I am using said patch, it does *not* solve all the problems
I'm experiencing, I have already posted to say it fixes
*one* problem

regardless of blame, uninstalling compiz solves all my issues

Who said anything about intel cards?

To reiterate the patch (actually 1 less patch in xorg)
doesn't solve *ALL* problems I'm having with
compiz with an nvidia card

Disabling or uninstalling compiz *does*

I care not whos "fault" it is or the politics
compiz+xorg+nvidia glx is NOT production ready

Ralf Nieuwenhuijsen wrote:
> Maybe I am missing the point ..
>
> 1) Compiz is not on by default for NVidia
>
> But if you own an Nvidia card, then there is no compiz by default!
> Why do people insist on claiming that there is?
>
> You are M-A-N-U-A-L-L-Y installing an U-N-S-U-P-P-O-R-T-E-D driver.
> After which compiz is enabled by default, because the driver _claims_ it supports 3d.
> Unfortunately this driver is incompatible with the particular XServer of Gutsy, hence the driver crashes.
> If this is not fixed before gutsy launch, i'm pretty sure nvidia will be on the blacklist and compiz will not be enabled for Nvidia users.
>
> No freaking reason to disable compiz for Intel videocards, because
> Nvidia won't work. That makes no sense.
>
> 2) There is test package of xserver that FIXES those issues. If you
> bother to read the whole thread you would know that. You can test that
> package yourself. The more people that claim that it 'works' .. the more
> likely the patch will be included in gutsy.
>
> When the patch is included in gutsy and it fixes the problem, then
> nvidia won't need to be blacklisted.
>
> 3) There are valid arguments against enabling compiz by default for
> anyone. But this aint one of them. This is nvidia-specific crashes, for
> which a working patch exists, that have got nothing to do with compiz.
>
> Stop the FUD please.
>
>

Calm down, we're not here to talk about anything beyond the scope of the
bug. None of us mind listening, but you're really not telling the right
people. The issue at hand is just a temporary one. (Presumably) when
nvidia reaches xorg compatibility this should be no issue now that it's
upstream.

ChrisC wrote:
> I am using said patch, it does *not* solve all the problems
> I'm experiencing, I have already posted to say it fixes
> *one* problem
>
> regardless of blame, uninstalling compiz solves all my issues
>
> Who said anything about intel cards?
>
> To reiterate the patch (actually 1 less patch in xorg)
> doesn't solve *ALL* problems I'm having with
> compiz with an nvidia card
>
> Disabling or uninstalling compiz *does*
>
> I care not whos "fault" it is or the politics
> compiz+xorg+nvidia glx is NOT production ready
>
>
> Ralf Nieuwenhuijsen wrote:
>
>> Maybe I am missing the point ..
>>
>> 1) Compiz is not on by default for NVidia
>>
>> But if you own an Nvidia card, then there is no compiz by default!
>> Why do people insist on claiming that there is?
>>
>> You are M-A-N-U-A-L-L-Y installing an U-N-S-U-P-P-O-R-T-E-D driver.
>> After which compiz is enabled by default, because the driver _claims_ it supports 3d.
>> Unfortunately this driver is incompatible with the particular XServer of Gutsy, hence the driver crashes.
>> If this is not fixed before gutsy launch, i'm pretty sure nvidia will be on the blacklist and compiz will not be enabled for Nvidia users.
>>
>> No freaking reason to disable compiz for Intel videocards, because
>> Nvidia won't work. That makes no sense.
>>
>> 2) There is test package of xserver that FIXES those issues. If you
>> bother to read the whole thread you would know that. You can test that
>> package yourself. The more people that claim that it 'works' .. the more
>> likely the patch will be included in gutsy.
>>
>> When the patch is included in gutsy and it fixes the problem, then
>> nvidia won't need to be blacklisted.
>>
>> 3) There are valid arguments against enabling compiz by default for
>> anyone. But this aint one of them. This is nvidia-specific crashes, for
>> which a working patch exists, that have got nothing to do with compiz.
>>
>> Stop the FUD please.
>>
>>
>>
>
>

On 17/09/2007, Ralf Nieuwenhuijsen <email address hidden> wrote:

> Maybe I am missing the point ..
>
> 1) Compiz is not on by default for NVidia
>
> But if you own an Nvidia card, then there is no compiz by default!
> Why do people insist on claiming that there is?

The first time you run X after a clean install of gutsy, it tells you
that you can enable restricted drivers for better functionality and
offers a dialog to do so -- every new user with an nvidia card will
see that, and most will probably choose it. As soon as you do that
and reboot, compiz will start causing problems; if you don't do that,
you can't use 3D apps with nvidia. If you want to use 3D apps, you
have to figure out on your own (no automatic prompts) to go to the
System/Preferences/Appearance dialog, choose the "Desktop" tab, and
check the "No effects" radio button. That's not intuitive.

I agree that this problem will affect only a minority of Ubuntu users
-- probably less than 20% -- and that it's nvidia's fault rather than
compiz's, but what benefits do we get from defaulting to compiz to
offset that problem? Why not make gutsy stable for those users as
well? You're not really doing anything useful for the other 80%
anyway, aside from a bit of eye candy.

All the best,

David

On 17/09/2007, Bryan Haskins <email address hidden> wrote:

> Again see my last reply there, but this again is straying off topic. My
> understanding is that the system will actually be checked for proper
> compatibility before all of this. Worst case, it tries to start up, X
> dies, and restarts in Compatibility mode, Compiz is disabled, and all's
> fine, but the regular check should catch most things, so no worries =]

It's not checked now. Does someone plan to implement that in gutsy in
the next four weeks, or is there already a feature freeze?

All the best,

David

Hmm really? I hadn't been testing, it was planned.

David Megginson wrote:
> On 17/09/2007, Bryan Haskins <email address hidden> wrote:
>
>
>> Again see my last reply there, but this again is straying off topic. My
>> understanding is that the system will actually be checked for proper
>> compatibility before all of this. Worst case, it tries to start up, X
>> dies, and restarts in Compatibility mode, Compiz is disabled, and all's
>> fine, but the regular check should catch most things, so no worries =]
>>
>
> It's not checked now. Does someone plan to implement that in gutsy in
> the next four weeks, or is there already a feature freeze?
>
>
> All the best,
>
>
> David
>
>

kees cook's package fix the issue for me on x86-64 with a GeForce 7300 LE

100.14.19 has been released! Let's hope it works.

http://www.nvnews.net/vbulletin/showpost.php?p=1381746&postcount=20

sudo aptitude dist-upgrade today + installed the 100.14.19 drivers Richard mentioned. compiz with desktop effects on + the screensaver crashes my system still.

With desktop effects off, compiz is using 50% of my processor time. I have no idea what that is about. I'm on a duo-core laptop. So compiz sure is busy with something...

Fix scheduled to be uploaded in xorg-server 1.3.0.0.dfsg-12ubuntu5

(Not an l-r-m issue really)

will it make its way into gutsy release??

-----Original Message-----
From: Richard Ayotte <email address hidden>
Reply-To: Bug 130325 <email address hidden>
To: <email address hidden>
Subject: [Bug 130325] Re: [nvidia-glx] 3D GL apps crash X when using
compiz due to unmaked ABI change (gutsy)
Date: Tue, 18 Sep 2007 21:43:14 -0000

100.14.19 has been released! Let's hope it works.

http://www.nvnews.net/vbulletin/showpost.php?p=1381746&postcount=20

xorg-server (2:1.3.0.0.dfsg-12ubuntu5) gutsy; urgency=low

  [ Kees Cook ]
  * debian/patches/132_composite-no-clipping.diff: Adjusted WindowRec
    structure order and RedirectDraw logic to avoid nvidia crashes
    (fixes LP: #130325).
  * debian/patches/100_security_fdo-bug-7447.diff: Composite used for
    pixmap population on redirect. [CVE-2007-4730]

 -- Bryce Harrington <email address hidden> Tue, 18 Sep 2007 17:20:14 -0700

i Just upgraded my Googleearth version (downloaded the latest from Google) and it is crashing X again. GLX gears and other 3d games are working fine...its just google earth...

Note: even previous version crashes X//

sometimes it crashes the whole system and then i have to hard boot it... cant even do alt+print sc+r+e+i+s+u+b

On 04/10/2007, Re Alvarez wrote:

> i Just upgraded my Googleearth version (downloaded the latest from
> Google) and it is crashing X again. GLX gears and other 3d games are
> working fine...its just google earth...

Is it crashing only when you run compiz? I haven't used compiz at all
since I realized it was crashing my 3D apps, so I haven't tracked any
progress.

All the best,

David

@David

Yes only with Compiz...