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

[Steven Ketelsen]

Binary package hint: xserver-xorg

Compiz works beautifully on my 32-bit Athlon XP running gutsy gibbon Tribe 3, on an nVidia GeForce FX 5900XT 128MB card. When glxgears or other 3d apps (neverball, vendetta) are started when compiz is running, X hard crashes. Some opengl screensavers run well.

All 3d applications run well if compiz is disabled.

xorg.0.log: (backtrace at bottom)
[code]
X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Linux Ubuntu
Current Operating System: Linux monolith 2.6.22-9-generic #1 SMP Fri Aug 3 00:50:37 GMT 2007 i686
Build Date: 26 July 2007
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Aug 4 02:12:19 2007
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) | |-->Monitor "Dell Trinitron 21"
(**) | |-->Device "GeForce FX 5900"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(**) |-->Input Device "stylus"
(**) |-->Input Device "cursor"
(**) |-->Input Device "eraser"
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
 Entry deleted from font path.
(==) FontPath set to:
 /usr/share/fonts/X11/misc,
 /usr/share/fonts/X11/100dpi/:unscaled,
 /usr/share/fonts/X11/75dpi/:unscaled,
 /usr/share/fonts/X11/Type1,
 /usr/share/fonts/X11/100dpi,
 /usr/share/fonts/X11/75dpi,
 /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Loader magic: 0x81e5980
(II) Module ABI versions:
 X.Org ANSI C Emulation: 0.3
 X.Org Video Driver: 1.2
 X.Org XInput driver : 0.7
 X.Org Server Extension : 0.3
 X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.0.0
 ABI class: X.Org Video Driver, version 1.2
(++) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,3189 card 1458,5000 rev 80 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,b198 card 0000,0000 rev 00 class 06,04,00 hdr 01
(II) PCI: 00:0a:0: chip 1131,7130 card 5168,0138 rev 01 class 04,80,00 hdr 00
(II) PCI: 00:0b:0: chip 168c,001a card 1186,3a16 rev 01 class 02,00,00 hdr 00
(II) PCI: 00:0c:0: chip 1102,0004 card 1102,0058 rev 03 class 04,01,00 hdr 80
(II) PCI: 00:0c:2: chip 1102,4001 card 1102,0010 rev 01 class 0c,00,10 hdr 80
(II) PCI: 00:0f:0: chip 1106,0571 card 1458,5002 rev 06 class 01,01,8a hdr 00
(II) PCI: 00:10:0: chip 1106,3038 card 1458,5004 rev 81 class 0c,03,00 hdr 80
(II) PCI: 00:10:1: chip 1106,3038 card 1458,5004 rev 81 class 0c,03,00 hdr 80
(II) PCI: 00:10:2: chip 1106,3038 card 1458,5004 rev 81 class 0c,03,00 hdr 80
(II) PCI: 00:10:3: chip 1106,3038 card 1458,5004 rev 81 class 0c,03,00 hdr 80
(II) PCI: 00:10:4: chip 1106,3104 card 1458,5004 rev 86 class 0c,03,20 hdr 80
(II) PCI: 00:11:0: chip 1106,3227 card 1458,5001 rev 00 class 06,01,00 hdr 80
(II) PCI: 00:11:5: chip 1106,3059 card 0000,0000 rev 60 class 04,01,00 hdr 00
(II) PCI: 00:13:0: chip 10ec,8139 card 1458,e000 rev 10 class 02,00,00 hdr 00
(II) PCI: 00:14:0: chip 1106,3044 card 1458,1000 rev 46 class 0c,00,10 hdr 00
(II) PCI: 01:00:0: chip 10de,0332 card 0000,0000 rev a1 class 03,00,00 hdr 00
(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
 [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
 [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
 [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set)
(II) Bus 1 non-prefetchable memory range:
 [0] -1 0 0xe0000000 - 0xe1ffffff (0x2000000) MX[B]
(II) Bus 1 prefetchable memory range:
 [0] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B]
(II) PCI-to-ISA bridge:
(II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
(--) PCI:*(1:0:0) nVidia Corporation NV35 [GeForce FX 5900XT] rev 161, Mem @ 0xe0000000/24, 0xd8000000/27
(II) Addressable bus resource ranges are
 [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
 [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) OS-reported resource ranges:
 [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
 [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
 [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
 [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
 [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
 [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
(II) PCI Memory resource overlap reduced 0xd0000000 from 0xd7ffffff to 0xcfffffff
(II) Active PCI resource ranges:
 [0] -1 0 0xe2018000 - 0xe20187ff (0x800) MX[B]
 [1] -1 0 0xe2017000 - 0xe20170ff (0x100) MX[B]
 [2] -1 0 0xe2016000 - 0xe20160ff (0x100) MX[B]
 [3] -1 0 0xe2010000 - 0xe2013fff (0x4000) MX[B]
 [4] -1 0 0xe2014000 - 0xe20147ff (0x800) MX[B]
 [5] -1 0 0xe2000000 - 0xe200ffff (0x10000) MX[B]
 [6] -1 0 0xe2015000 - 0xe20153ff (0x400) MX[B]
 [7] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
 [8] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
 [9] -1 0 0xe0000000 - 0xe0ffffff (0x1000000) MX[B](B)
 [10] -1 0 0x0000ec00 - 0x0000ec7f (0x80) IX[B]
 [11] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
 [12] -1 0 0x00001000 - 0x000010ff (0x100) IX[B]
 [13] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B]
 [14] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B]
 [15] -1 0 0x0000dc00 - 0x0000dc1f (0x20) IX[B]
 [16] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B]
 [17] -1 0 0x0000d400 - 0x0000d40f (0x10) IX[B]
 [18] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
(II) Active PCI resource ranges after removing overlaps:
 [0] -1 0 0xe2018000 - 0xe20187ff (0x800) MX[B]
 [1] -1 0 0xe2017000 - 0xe20170ff (0x100) MX[B]
 [2] -1 0 0xe2016000 - 0xe20160ff (0x100) MX[B]
 [3] -1 0 0xe2010000 - 0xe2013fff (0x4000) MX[B]
 [4] -1 0 0xe2014000 - 0xe20147ff (0x800) MX[B]
 [5] -1 0 0xe2000000 - 0xe200ffff (0x10000) MX[B]
 [6] -1 0 0xe2015000 - 0xe20153ff (0x400) MX[B]
 [7] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
 [8] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
 [9] -1 0 0xe0000000 - 0xe0ffffff (0x1000000) MX[B](B)
 [10] -1 0 0x0000ec00 - 0x0000ec7f (0x80) IX[B]
 [11] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
 [12] -1 0 0x00001000 - 0x000010ff (0x100) IX[B]
 [13] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B]
 [14] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B]
 [15] -1 0 0x0000dc00 - 0x0000dc1f (0x20) IX[B]
 [16] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B]
 [17] -1 0 0x0000d400 - 0x0000d40f (0x10) IX[B]
 [18] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
(II) OS-reported resource ranges after removing overlaps with PCI:
 [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
 [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
 [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
 [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
 [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
 [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
(II) All system resource ranges:
 [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
 [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
 [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
 [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
 [4] -1 0 0xe2018000 - 0xe20187ff (0x800) MX[B]
 [5] -1 0 0xe2017000 - 0xe20170ff (0x100) MX[B]
 [6] -1 0 0xe2016000 - 0xe20160ff (0x100) MX[B]
 [7] -1 0 0xe2010000 - 0xe2013fff (0x4000) MX[B]
 [8] -1 0 0xe2014000 - 0xe20147ff (0x800) MX[B]
 [9] -1 0 0xe2000000 - 0xe200ffff (0x10000) MX[B]
 [10] -1 0 0xe2015000 - 0xe20153ff (0x400) MX[B]
 [11] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
 [12] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
 [13] -1 0 0xe0000000 - 0xe0ffffff (0x1000000) MX[B](B)
 [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
 [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
 [16] -1 0 0x0000ec00 - 0x0000ec7f (0x80) IX[B]
 [17] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
 [18] -1 0 0x00001000 - 0x000010ff (0x100) IX[B]
 [19] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B]
 [20] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B]
 [21] -1 0 0x0000dc00 - 0x0000dc1f (0x20) IX[B]
 [22] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B]
 [23] -1 0 0x0000d400 - 0x0000d40f (0x10) IX[B]
 [24] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules//libglx.so
(II) Module glx: vendor="NVIDIA Corporation"
 compiled for 4.0.2, module version = 1.0.9755
 Module class: X.Org Server Extension
 ABI class: X.Org Server Extension, version 0.1
(II) Loading extension GLX
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.0.0
 Module class: X.Org Server Extension
 ABI class: X.Org Server Extension, version 0.3
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /usr/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.0.0
 Module class: X.Org Server Extension
 ABI class: X.Org Server Extension, version 0.3
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "freetype"
(II) Loading /usr/lib/xorg/modules//fonts/libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
 compiled for 1.3.0, module version = 2.1.0
 Module class: X.Org Font Renderer
 ABI class: X.Org Font Renderer, version 0.5
(II) Loading font FreeType
(II) LoadModule: "type1"
(II) Loading /usr/lib/xorg/modules//fonts/libtype1.so
(II) Module type1: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.0.2
 Module class: X.Org Font Renderer
 ABI class: X.Org Font Renderer, version 0.5
(II) Loading font Type1
(II) LoadModule: "record"
(II) Loading /usr/lib/xorg/modules/extensions//librecord.so
(II) Module record: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.13.0
 Module class: X.Org Server Extension
 ABI class: X.Org Server Extension, version 0.3
(II) Loading extension RECORD
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.0.0
 ABI class: X.Org Server Extension, version 0.3
(II) Loading extension XFree86-DRI
(II) LoadModule: "nvidia"
(II) Loading /usr/lib/xorg/modules/drivers//nvidia_drv.so
(II) Module nvidia: vendor="NVIDIA Corporation"
 compiled for 4.0.2, module version = 1.0.9755
 Module class: X.Org Video Driver
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules/input//kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.2.1
 Module class: X.Org XInput Driver
 ABI class: X.Org XInput driver, version 0.7
(II) LoadModule: "mouse"
(II) Loading /usr/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.2.1
 Module class: X.Org XInput Driver
 ABI class: X.Org XInput driver, version 0.7
(II) LoadModule: "wacom"
(II) Loading /usr/lib/xorg/modules/input//wacom_drv.so
(II) Module wacom: vendor="X.Org Foundation"
 compiled for 4.3.99.902, module version = 1.0.0
 Module class: X.Org XInput Driver
 ABI class: X.Org XInput driver, version 0.7
(II) Wacom driver level: 47-0.7.7-7 $
(II) NVIDIA dlloader X Driver 1.0-9755 Mon Feb 26 23:23:13 PST 2007
(II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
(II) Primary Device is: PCI 01:00:0
(--) Assigning device section with no busID to primary device
(--) Chipset NVIDIA GPU found
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules//libfb.so
(II) Module fb: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.0.0
 ABI class: X.Org ANSI C Emulation, version 0.3
(II) Loading sub module "wfb"
(II) LoadModule: "wfb"
(WW) Warning, couldn't open module wfb
(II) UnloadModule: "wfb"
(EE) Failed to load module "wfb" (module does not exist, 0)
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"(II) Module already built-in
(II) resource ranges after xf86ClaimFixedResources() call:
 [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
 [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
 [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
 [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
 [4] -1 0 0xe2018000 - 0xe20187ff (0x800) MX[B]
 [5] -1 0 0xe2017000 - 0xe20170ff (0x100) MX[B]
 [6] -1 0 0xe2016000 - 0xe20160ff (0x100) MX[B]
 [7] -1 0 0xe2010000 - 0xe2013fff (0x4000) MX[B]
 [8] -1 0 0xe2014000 - 0xe20147ff (0x800) MX[B]
 [9] -1 0 0xe2000000 - 0xe200ffff (0x10000) MX[B]
 [10] -1 0 0xe2015000 - 0xe20153ff (0x400) MX[B]
 [11] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
 [12] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
 [13] -1 0 0xe0000000 - 0xe0ffffff (0x1000000) MX[B](B)
 [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
 [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
 [16] -1 0 0x0000ec00 - 0x0000ec7f (0x80) IX[B]
 [17] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
 [18] -1 0 0x00001000 - 0x000010ff (0x100) IX[B]
 [19] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B]
 [20] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B]
 [21] -1 0 0x0000dc00 - 0x0000dc1f (0x20) IX[B]
 [22] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B]
 [23] -1 0 0x0000d400 - 0x0000d40f (0x10) IX[B]
 [24] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
(II) resource ranges after probing:
 [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
 [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
 [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
 [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
 [4] -1 0 0xe2018000 - 0xe20187ff (0x800) MX[B]
 [5] -1 0 0xe2017000 - 0xe20170ff (0x100) MX[B]
 [6] -1 0 0xe2016000 - 0xe20160ff (0x100) MX[B]
 [7] -1 0 0xe2010000 - 0xe2013fff (0x4000) MX[B]
 [8] -1 0 0xe2014000 - 0xe20147ff (0x800) MX[B]
 [9] -1 0 0xe2000000 - 0xe200ffff (0x10000) MX[B]
 [10] -1 0 0xe2015000 - 0xe20153ff (0x400) MX[B]
 [11] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
 [12] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
 [13] -1 0 0xe0000000 - 0xe0ffffff (0x1000000) MX[B](B)
 [14] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B]
 [15] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B]
 [16] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B]
 [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
 [18] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
 [19] -1 0 0x0000ec00 - 0x0000ec7f (0x80) IX[B]
 [20] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
 [21] -1 0 0x00001000 - 0x000010ff (0x100) IX[B]
 [22] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B]
 [23] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B]
 [24] -1 0 0x0000dc00 - 0x0000dc1f (0x20) IX[B]
 [25] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B]
 [26] -1 0 0x0000d400 - 0x0000d40f (0x10) IX[B]
 [27] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
 [28] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
 [29] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(II) Setting vga for screen 0.
(**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
(==) NVIDIA(0): RGB weight 888
(==) NVIDIA(0): Default visual is TrueColor
(==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
(**) NVIDIA(0): Option "NvAGP" "1"
(**) NVIDIA(0): Option "AddARGBGLXVisuals" "True"
(**) NVIDIA(0): Enabling RENDER acceleration
(**) NVIDIA(0): Use of NVIDIA internal AGP requested
(II) NVIDIA(0): Support for GLX with the Damage and Composite X extensions is
(II) NVIDIA(0): enabled.
(WW) NVIDIA(GPU-0): Unable to read EDID for display device CRT-0
(II) NVIDIA(0): NVIDIA GPU GeForce FX 5900XT at PCI:1:0:0 (GPU-0)
(--) NVIDIA(0): Memory: 131072 kBytes
(--) NVIDIA(0): VideoBIOS: 04.35.20.45.00
(II) NVIDIA(0): Detected AGP rate: 8X
(--) NVIDIA(0): Interlaced video modes are supported on this GPU
(--) NVIDIA(0): Connected display device(s) on GeForce FX 5900XT at
(--) NVIDIA(0): PCI:1:0:0:
(--) NVIDIA(0): CRT-0
(--) NVIDIA(0): SONY CPD-G400 (CRT-1)
(--) NVIDIA(0): CRT-0: 400.0 MHz maximum pixel clock
(--) NVIDIA(0): SONY CPD-G400 (CRT-1): 400.0 MHz maximum pixel clock
(II) NVIDIA(0): Assigned Display Device: CRT-0
(II) NVIDIA(0): Validated modes:
(II) NVIDIA(0): "1280x1024"
(II) NVIDIA(0): "1280x960"
(II) NVIDIA(0): "1152x864"
(II) NVIDIA(0): "1024x768"
(II) NVIDIA(0): "800x600"
(II) NVIDIA(0): "640x480"
(II) NVIDIA(0): Virtual screen size determined to be 1280 x 1024
(WW) NVIDIA(0): Unable to get display device CRT-0's EDID; cannot compute DPI
(WW) NVIDIA(0): from CRT-0's EDID.
(==) NVIDIA(0): DPI set to (75, 75); computed from built-in default
(--) Depth 24 pixmap format is 32 bpp
(II) do I need RAC? No, I don't.
(II) resource ranges after preInit:
 [0] 0 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B]
 [1] 0 0 0xe0000000 - 0xe0ffffff (0x1000000) MX[B]
 [2] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
 [3] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
 [4] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
 [5] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
 [6] -1 0 0xe2018000 - 0xe20187ff (0x800) MX[B]
 [7] -1 0 0xe2017000 - 0xe20170ff (0x100) MX[B]
 [8] -1 0 0xe2016000 - 0xe20160ff (0x100) MX[B]
 [9] -1 0 0xe2010000 - 0xe2013fff (0x4000) MX[B]
 [10] -1 0 0xe2014000 - 0xe20147ff (0x800) MX[B]
 [11] -1 0 0xe2000000 - 0xe200ffff (0x10000) MX[B]
 [12] -1 0 0xe2015000 - 0xe20153ff (0x400) MX[B]
 [13] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
 [14] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
 [15] -1 0 0xe0000000 - 0xe0ffffff (0x1000000) MX[B](B)
 [16] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
 [17] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
 [18] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
 [19] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
 [20] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
 [21] -1 0 0x0000ec00 - 0x0000ec7f (0x80) IX[B]
 [22] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
 [23] -1 0 0x00001000 - 0x000010ff (0x100) IX[B]
 [24] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B]
 [25] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B]
 [26] -1 0 0x0000dc00 - 0x0000dc1f (0x20) IX[B]
 [27] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B]
 [28] -1 0 0x0000d400 - 0x0000d40f (0x10) IX[B]
 [29] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
 [30] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
 [31] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU)
(II) NVIDIA(0): Setting mode "1280x1024"
(II) Loading extension NV-GLX
(II) NVIDIA(0): NVIDIA 3D Acceleration Architecture Initialized
(II) NVIDIA(0): Using the NVIDIA 2D acceleration architecture
(==) NVIDIA(0): Backing store disabled
(==) NVIDIA(0): Silken mouse enabled
(**) Option "dpms"
(**) NVIDIA(0): DPMS enabled
(II) Loading extension NV-CONTROL
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension XAccessControlExtension
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
(II) Initializing extension GLX
(**) Option "CoreKeyboard"
(**) Generic Keyboard: Core Keyboard
(**) Option "Protocol" "standard"
(**) Generic Keyboard: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Generic Keyboard: XkbRules: "xorg"
(**) Option "XkbModel" "pc105"
(**) Generic Keyboard: XkbModel: "pc105"
(**) Option "XkbLayout" "us"
(**) Generic Keyboard: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Generic Keyboard: CustomKeycodes disabled
(**) Option "Protocol" "ImPS/2"
(**) Configured Mouse: Device: "/dev/input/mice"
(**) Configured Mouse: Protocol: "ImPS/2"
(**) Option "CorePointer"
(**) Configured Mouse: Core Pointer
(**) Option "Device" "/dev/input/mice"
(==) Configured Mouse: Emulate3Buttons, Emulate3Timeout: 50
(**) Option "ZAxisMapping" "4 5"
(**) Configured Mouse: ZAxisMapping: buttons 4 and 5
(**) Configured Mouse: Buttons: 9
(**) Configured Mouse: Sensitivity: 1
(**) Option "SendCoreEvents"
(**) stylus: always reports core events
(**) stylus device is /dev/input/wacom
(**) stylus is in absolute mode
(**) stylus: forcing TabletPC ISD V4 protocol
(**) WACOM: suppress value is 2
(**) Option "BaudRate" "9600"
(**) stylus: serial speed 9600
(**) Option "SendCoreEvents"
(**) cursor: always reports core events
(**) cursor device is /dev/input/wacom
(**) cursor is in relative mode
(**) cursor: forcing TabletPC ISD V4 protocol
(**) WACOM: suppress value is 2
(**) Option "BaudRate" "9600"
(**) cursor: serial speed 9600
(**) Option "SendCoreEvents"
(**) eraser: always reports core events
(**) eraser device is /dev/input/wacom
(**) eraser is in absolute mode
(**) eraser: forcing TabletPC ISD V4 protocol
(**) WACOM: suppress value is 2
(**) Option "BaudRate" "9600"
(**) eraser: serial speed 9600
(II) XINPUT: Adding extended input device "eraser" (type: Wacom Eraser)
(II) XINPUT: Adding extended input device "cursor" (type: Wacom Cursor)
(II) XINPUT: Adding extended input device "stylus" (type: Wacom Stylus)
(II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)
(II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD)
(**) Option "Device" "/dev/input/wacom"
(EE) xf86OpenSerial: Cannot open device /dev/input/wacom
 No such file or directory.
Error opening /dev/input/wacom : Success
(**) Option "Device" "/dev/input/wacom"
(EE) xf86OpenSerial: Cannot open device /dev/input/wacom
 No such file or directory.
Error opening /dev/input/wacom : Success
(**) Option "Device" "/dev/input/wacom"
(EE) xf86OpenSerial: Cannot open device /dev/input/wacom
 No such file or directory.
Error opening /dev/input/wacom : Success
(II) Configured Mouse: ps2EnableDataReporting: succeeded

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x81) [0x80c8631]
1: [0xffffe420]
2: /usr/bin/X(Xfree+0x21) [0x81bff91]
3: /usr/lib/xorg/modules/drivers//nvidia_drv.so(_nv002357X+0x202) [0xb7155486]
4: [(nil)]

Fatal server error:
Caught signal 11. Server aborting
[/code]

/etc/X11/xorg.conf:

[code]
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig: version 1.0 (buildmeister@builder3) Mon Feb 26 23:38:46 PST 2007

# xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "ServerLayout"
    Identifier "Default Layout"
    Screen "Default Screen" 0 0
    InputDevice "Generic Keyboard"
    InputDevice "Configured Mouse"
    InputDevice "stylus" "SendCoreEvents"
    InputDevice "cursor" "SendCoreEvents"
    InputDevice "eraser" "SendCoreEvents"
EndSection

Section "Files"
EndSection

Section "Module"
    Load "glx"
EndSection

Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "pc105"
    Option "XkbLayout" "us"
EndSection

Section "InputDevice"
    Identifier "Configured Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "ImPS/2"
    Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    Identifier "stylus"
    Driver "wacom"
    Option "Device" "/dev/input/wacom"
    Option "Type" "stylus"
    Option "ForceDevice" "ISDV4" # Tablet PC ONLY
EndSection

Section "InputDevice"
    Identifier "eraser"
    Driver "wacom"
    Option "Device" "/dev/input/wacom"
    Option "Type" "eraser"
    Option "ForceDevice" "ISDV4" # Tablet PC ONLY
EndSection

Section "InputDevice"
    Identifier "cursor"
    Driver "wacom"
    Option "Device" "/dev/input/wacom"
    Option "Type" "cursor"
    Option "ForceDevice" "ISDV4" # Tablet PC ONLY
EndSection

Section "Monitor"
    Identifier "Dell Trinitron 21"
    HorizSync 30.0 - 107.0
    VertRefresh 48.0 - 120.0
    Option "DPMS"
EndSection

Section "Device"
    Identifier "GeForce FX 5900"
    Driver "nvidia"
EndSection

Section "Screen"
    Identifier "Default Screen"
    Device "GeForce FX 5900"
    Monitor "Dell Trinitron 21"
    DefaultDepth 24
    Option "AddARGBGLXVisuals" "True"
    Option "NvAGP" "1"
# Option "RenderAccel" "True"
# Option "NoRenderExtension" "False"
# Option "TwinView" "True"
# Option "NoFlip" "False"
# Option "XvmcUsesTextures" "True"
# Option "MetaModes" "nvidia-auto-select, nvidia-auto-select"
# Option "TwinViewOrientation" "RightOf"
    SubSection "Display"
        Depth 24
        Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
    EndSubSection
EndSection
[/code]
[code]
 cat /proc/driver/nvidia/agp/*
Fast Writes: Supported
SBA: Supported
AGP Rates: 8x 4x
Registers: 0x1f000e1b:0x1f000302
Host Bridge: PCI device 1106:3189
Fast Writes: Supported
SBA: Supported
AGP Rates: 8x 4x
Registers: 0x1f000a1b:0x00000b02
Status: Enabled
Driver: NVIDIA
AGP Rate: 8x
Fast Writes: Disabled
SBA: Enabled
[/code]

Let me know if more info is needed.

[John Pham (jhnphm)]

Can confirm it here too on x86_64 w/ intel_agp disabled

[John Pham (jhnphm)]

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

[John Pham (jhnphm)]

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

[John Pham (jhnphm)]

Probably should be merged w/ bug #130914

[Sitsofe Wheeler (sitsofe)]

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.

[Bryan Haskins (bryan-h)]

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.

[Sitsofe Wheeler (sitsofe)]

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...

[Suzan (suzan72)]

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.

[Bryan Haskins (bryan-h)]

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.)

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

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.

[Sanjaya Karunasena (sanjayak)]

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.

[Suzan (suzan72)]

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.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

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..

[mysteryweapon (plesko)]

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

[Sanjaya Karunasena (sanjayak)]

>> 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.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

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

[Christopher Fredericks (zsouthboy)]

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.

[Bryan Haskins (bryan-h)]

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

--
Cheers,
Bryan

[Cyrilou (mouarf-mouarf)]

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.

[Sanjaya Karunasena (sanjayak)]

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.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

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.

[Re Alvarez (re-alvz)]

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?

[Sitsofe Wheeler (sitsofe)]

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.

[Cyrilou (mouarf-mouarf)]

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.

[Christoph Lechleitner (lech)]

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.

[Sitsofe Wheeler (sitsofe)]

(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 .

[Pedro Vanzella (ppvanzella)]

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).

[emmanuel (le-unamme)]

same here

[wgscott (wgscott)]

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.

[TJ (tj)]

Confirmed with Gutsy Tribe-5 64-bit.

[Sitsofe Wheeler (sitsofe)]

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.

[wgscott (wgscott)]

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.

[Michael Vogt (mvo)]

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 ?? ()

[Michael Vogt (mvo)]

$ 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 ?? ()

[Michael Vogt (mvo)]

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.

[Sitsofe Wheeler (sitsofe)]

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?

[Mirco Müller (macslow)]

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

[wgscott (wgscott)]

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?

[Bryan Haskins (bryan-h)]

Agreed, still broken.

[wgscott (wgscott)]

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

[Sitsofe Wheeler (sitsofe)]

Thanks for the speedy replies.

I guess my next question is - can someone recompile xorg and narrow the problem patch down? If people want a blind guess as to which patch it was I'd go with 132:

The original report says that Xorg worked in the Gutsy tribe 3 release. According to http://cdimage.ubuntu.com/releases/gutsy/tribe-3/ this was release on the 17th-18th July. By 4th August the breakage had arrived.

Using the i386 alternate CD's file list (the desktop CDs file list seems very small and might be broken) we can tell that xserver-xorg-core_1.3.0.0.dfsg-6ubuntu2_i386.deb was what was shipped. Looking at the original reporter's xorg output we can tell the broken xorg was built on 26th July. Using the changelog on http://changelogs.ubuntu.com/changelogs/pool/main/x/xorg-server/xorg-server_1.3.0.0.dfsg-12ubuntu3/changelog the first August xorg build is apparently 2:1.3.0.0.dfsg-12 (it's a pity the reporter didn't include a xorg package version number in the original report, nor did xorg mention the package version number in its log).

I'd guess the problem patch was made (strictly) between the xserver-xorg-core_1.3.0.0.dfsg-6ubuntu2_i386.deb and 2:1.3.0.0.dfsg-12 releases. The dates in the changelog around July are a bit funny though. The only patch from then that seems to be in an area that would affect this bug is debian/patches/132_composite-no-clipping.diff which is why I would start around there. This is pure speculation though.

[Winckler (winckler)]

I'm really impressed with your bugtrace, very smart. But one additional info: The tribe-3 version has already broken. Thats what I can understand from the bug explanation and that is the version I installed (from a clean install) in my notebook and already had the bug. Note that in that time, we had to use the NVIDIA official installer.

Anyway in the weekend I will try recompile with n numbers of patches, and lets see what happens.

[Sitsofe Wheeler (sitsofe)]

Winckler:
Faulty logic (in my case that tribe 3's xorg worked) will get you ever time. Thanks for the debunking!

I guess we're back to square two. Assuming you can find a lower patched version of Xorg that works (which is possible according to Michael) you can use bisection (where you test half the patches that might contain the problem then half again etc) means that you should be able to narrow down the problem patch in no more than 8 tries. I guess if you are doing this you might want to report your progress if rebuilding xorg is going to take a long time in case someone can help...

Alternatively if someone can throw up 8 builds of xorg with different patches in them then I guess people can download them and report back their results...

[Greg Gilbert (greg-treke)]

I started doing builds this evening to test it and found that removing 132_composite-no-clipping.diff from the build does prevent the crash from occuring.

[Mirco Müller (macslow)]

I can confirm Greg's findings. Just skipping the patch "132_composite-no-clipping.diff" every OpenGL-based program I tried (glxgears, lowfat, blender, gl-gst-player, neverball) did not crash Xorg anymore. This was done on a GeForce 8800 GTS using the 100.14.11 driver (installed via the nvidia-glx-new package).

[Winckler (winckler)]

Yes, I can also confirm Greg's findings. Without the patch, everything works fine. But I don't have any clue what that patch means. There I have a NVidia GeForce 8400M, also with 100.14.11 driver from ubuntu packages.

[Bryan Haskins (bryan-h)]

Well this got more complicated... apparently this patch has gone upstream, and is required to make a few new things function. I was skimming the update/patch logs. This patch was removed early July (13th-ish?) and reinstated the 15th "fixed" no specific mentions of nvidia, but it was removed for some compiz issues, and re-added when the compiz issues were supposedly gone. Now this is interesting... short term, we could sort of weigh the options and maybe remove the patch from the build cycle, long term (next release) if this isn't fixed and we get the new upstream with this patch without it being fixed, it's far more annoying. So this is just getting rather crazy... Now when other peopel start using this patch, or start using the new upstream all applicable distros will see it, and no way it'd go unpatched for long. But it comes down to this:

It seems like in fixing a bug on our end, we exposed a great nvidia end bug... We could work aroudn this more properly, or we could leave it in the main distro tree to try and pressure nvidia to fix it (they really have no reason to listen, in all honesty)

I'm sure nVidia would eventually fix their end of it. But until then... heres what we can do:
1) if the options are weighed in the favor of Compiz support (realistically, almost everyone uses some form of compositing with ubuntu these days, if they can, it's just so easy for light effects to be done) then we will patch this back out of upstream/remove the current patch from the build tree, and there we go.

2) We decide that we shouldn't have to work around somethign we believe to be nvidia end in a grand stance against closed source software! (Sure it'll work well, nvidia will find the err in their ways, and whathaveyou, of course they will) Then I would recommend someone who knows X well to build a semi-official or 3rd party package to fix this (build it without the patch) and distribute it in some repository, and make it accessible, seems like something that might be fit for trevs Gutsy repo (getting in to the whole of package semantics later on)

Honestly, It's a big thing to just say "No we won't do things hackishly for you Mr. nVidia!" to essentially break use of Compiz with anything remotely useful in gutsy final.

Does anyone have the guts to tell people, specifically new users, that because of politics (mainly anywho), they will have to compile a copy of xserver themselves, or uninstall the current and replace it with an off named X which will crap out their metas, and so on. That's a lot to say!

I know it's not *only* politics, the patch was commited for a reason, but there we have it. X crashing Vs. a few things working properly otherwise (from what I hear about the patch, don't quote me on that.)

[Bryan Haskins (bryan-h)]

Sorry, this was reinstated the *25th*, not the 15th.

[wgscott (wgscott)]

I've seen on various mailing lists users of fedora core complaining of this bug since January of this year. So I don't think nvidia is going to feel any urgency implementing a fix.

I'm happy to test debian packages BTW, if there is any further need.

On Fri, 07 Sep 2007 22:36:14 -0000
Bryan Haskins <email address hidden> wrote:

     Well this got more complicated...

[Re Alvarez (re-alvz)]

Honestly...If i was a new user to begin my linux experience with
Gutsy...and i switched to linux just my cool friend had a desktop cube
(which believe me man....is the most compelling feature for normal
users...I've had my friends switch to ubuntu just because of beryl
mainly)...and i see that my system keeps crashing when i run 3d apps...i
wouldnt care to ask anybody why it happens..whose faults is it...nVidia
or linux...i'd shove my microsoft CD right in and become microsoft's
slave again very very happily.

just my opinion.

-----Original Message-----
From: Bryan Haskins <email address hidden>
Reply-To: Bug 130325 <email address hidden>
To: <email address hidden>
Subject: [Bug 130325] Re: [nvidia-glx-new] 3D GL apps crash X when using
compiz (gutsy)
Date: Fri, 07 Sep 2007 22:36:14 -0000

Well this got more complicated... apparently this patch has gone
upstream, and is required to make a few new things function. I was
skimming the update/patch logs. This patch was removed early July (13th-
ish?) and reinstated the 15th "fixed" no specific mentions of nvidia,
but it was removed for some compiz issues, and re-added when the compiz
issues were supposedly gone. Now this is interesting... short term, we
could sort of weigh the options and maybe remove the patch from the
build cycle, long term (next release) if this isn't fixed and we get the
new upstream with this patch without it being fixed, it's far more
annoying. So this is just getting rather crazy... Now when other peopel
start using this patch, or start using the new upstream all applicable
distros will see it, and no way it'd go unpatched for long. But it comes
down to this:

It seems like in fixing a bug on our end, we exposed a great nvidia end
bug... We could work aroudn this more properly, or we could leave it in
the main distro tree to try and pressure nvidia to fix it (they really
have no reason to listen, in all honesty)

I'm sure nVidia would eventually fix their end of it. But until then... heres what we can do:
1) if the options are weighed in the favor of Compiz support (realistically, almost everyone uses some form of compositing with ubuntu these days, if they can, it's just so easy for light effects to be done) then we will patch this back out of upstream/remove the current patch from the build tree, and there we go.

2) We decide that we shouldn't have to work around somethign we believe
to be nvidia end in a grand stance against closed source software! (Sure
it'll work well, nvidia will find the err in their ways, and
whathaveyou, of course they will) Then I would recommend someone who
knows X well to build a semi-official or 3rd party package to fix this
(build it without the patch) and distribute it in some repository, and
make it accessible, seems like something that might be fit for trevs
Gutsy repo (getting in to the whole of package semantics later on)

Honestly, It's a big thing to just say "No we won't do things hackishly
for you Mr. nVidia!" to essentially break use of Compiz with anything
remotely useful in gutsy final.

Does anyone have the guts to tell people, specifically new users, that
because of politics (mainly anywho), they will have to compile ...

[Kent deVillafranca (kdevilla)]

At this point, I think whatever the patch is supposed to fix can't possibly be worse than the side effects of the patch itself.

[Adam Klobukowski (adamklobukowski)]

My opinion:

Patch pros:
- This patch fixes 'something'.

Patch cons:
- This patch breaks all (?) setups with Nvidia 8xxx hardware and Compiz Fusion software

My opinion: if it is not known what this patch fixes, it should be dropped. If it is known, let the popularity-contest decide.

[Andy Morton (andy-morton)]

Taken from the archive of gutsy changes...

debian/patches/132_composite-no-clipping.diff: Change the semantics of manual-redirect Composite windows so that they do not clip sibling or parent drawing. Needed by hildon-desktop to prevent home applets from clipping.

[Bryce Harrington (bryce)]

Thanks everyone for narrowing it down to this patch.

The root issue appears to be that 132 modifies the ABI just slightly, which is fine for open source drivers since they are rebuilt, but for closed source drivers like -nvidia (and presumably others??) it leads to this crash.

The background on patch 132 is that it's necessary for Ubuntu Mobile, as without it the home apps get clipped and can't be seen, making the mobile UI unavailable. So dropping this patch would have an unfortunate impact on UME; I'm hoping a better all-around solution can be found within the next week or two.

[C Pirnat (histoplasmosis)]

Also confirmed on nvidia 7600gs running gusty with nvidia-glx and running apps such as glxgears or warsow will crash X sig term 11 and force it to restart.

[Timo Aaltonen (tjaalton)]

Since the patch is from upstream and included in the newly released xorg-server 1.4, the nvidia blob needs to be updated to reflect the change. Reassigning to l-r-m-2.6.22.

From what I remember, there should be a new driver coming later this month.

[Mirco Müller (macslow)]

Just for everybody to know... nvidia is aware of this issue at hand. So I would guess that the next driver-release will have that bug fixed.

And let's hope for the sake of users of ATI-hardware, who want/need the fglrx-driver, that AMD/ATI will not be a victim of this change in Xorg. With the recent annoucement of AMD/ATI trying hard to becoming a better OpenSource-citizen, my guess it that they are aware of this. Is there perhaps anybody from AMD/ATI reading this and able to reply? That would be nice!

[Peter Würtz (pwuertz)]

right as netllama from nvidia said
http://www.nvnews.net/vbulletin/showpost.php?p=1370452&postcount=15
this bug will be fixed in the next driver release, which is compatible to Xorg7.3 / xserver1.4

[flynux (flynux-wordpress-com)]

I had the same problem with a fresh install of Gutsy (tribe 5) and using the nvidia-glx-new package from the restricted driver manager (Nvidia 8600 GTS). The installer didn't install the package in the right way too and I had to manually edit xorg.conf. Every time I run 3D games the X server crashes.

[flynux (flynux-wordpress-com)]

I tried right now without compiz and all works perfectly... I dunno if the problem is really imputable to Xorg.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

@flynux .. which nvidia driver are you using?

Which programs are working? Some games still work, some don't.
Does glxgears work for you or not? With compiz enabled?

There seem to be an abi-mismatch with the nvidia driver and the xserver.
Ubuntu has backported a fix from the new xserver to this xserver to make the mobile platform work, but this backport changes the abi. Which means that we will nvidia to fix their driver. They will, but it might not be included in gutsy.

So the solutions would be:
  - remove the patch and break ubuntu-mobile (i don't think the ubuntu-devs want this)
  - ship seperate xorg's (yuck)
  - add a patch to make the clipping an option in xorg, and add the noclipping thingie in xorg.conf

[Adam Klobukowski (adamklobukowski)]

I think that Ubuntu userbase with Nvidia hardware affected by this bug, is much bigger then Ubuntu-mobile. Can't they make separate xserver package? I bet there are many other patches not suitable for desktop that would greatly help mobile users.

[Sitsofe Wheeler (sitsofe)]

(I am going to make this my last comment on this bug)

Maintaining two xorg packages would crank maintenance issues up dramatically and if it came to this I suspect a 3rd party would have to maintain the alternate xorg because doing so doesn't carry all the commitments of Ubuntu doing it (e.g. security updates).

I also think that arguing against the patch completely on the grounds of NVIDIA card popularity is the wrong way to go (I noticed some previous comments were tending to this). Yes NVIDIA cards ARE common but the patch fixes issues for Intel graphics card owners too. Approximately 40% of x86 PCs are shipped with Intel graphics cards in them. The rest of the market is split fairly evenly between NVIDIA and ATI cards and some small percentage are other graphics card makers (VIA, Matrox, SiS etc). See http://arstechnica.com/news.ars/post/20070730-nvidia-continues-to-take-graphics-market-share-from-amd-intel.html for the current estimates of the big three current percentage shipments. Note this comment refers to total graphics cards shipped - not just discrete cards.

My one thought in this is if an updated NVIDIA binary driver is released, how will it know which ABI it should target? Doesn't the current xorg indicate that it is the old ABI (which it isn't strictly true)? Obviously changing the ABI version will cause issues today (you would need to set the NVIDIA binary only driver to ignore the ABI) but would it go on to help things in the future?

[Yagisan (yagisan)]

my simple work around was to uninstall compiz, and turn off desktop effects, so it runs metacity as the window manager. Given the choice between compiz, or working opengl, I pick working opengl. bye bye compiz.

[3vi1 (launchpad-net-eternaldusk)]

I hope nVidia gets on the ball and releases a new driver in time for everyone to test before Gutsy final (now that it has been voted that Compiz will be enabled by default). If they don't, I think Gutsy will end up looking very unstable to users unfamiliar with the underlying causes.

I have this problem on my 7600GT-based system and it's getting annoying to switch window managers every time I want to run an OpenGL app. I do *not* hope the 'buntu maintainers build Xorg without patch 132 as a workaround though, as that completely removes all incentive for nVidia to fix the real problem.

In answer to Sitsofe's ABI observation, I would think that nVidia would simply put an item in the release notes indicating that the newer driver is only for Xorg (insert version # / patch level here) and later. It would be up to the repackagers to set dependencies for each version to their related Xorg packages.

-J

[ChrisC (chris-chris-camacho-deactivatedaccount)]

making compiz enabled by default with this issue *regardless* of blame
would be disastrous and could seriously dent efforts to correct bug #1
it could even mean Ubuntu becoming a minor bit player of distros...

Is this *defiantly* an nvidia bug, are people really sure that there isnt
a bug with the clipping patch for xorg?

Can the clipping patch not be altered to take into account nvidia
drivers?

theres a legacy nvidia an open source nvidia an older nvidia and
an nividia-glx-new driver why not an nvidia-mobile driver too :o)

enabling compiz by default with this bug could kill Ubuntu.
This needs sorting *well* before November October is only
a few weeks away...

3vi1 wrote:
> I hope nVidia gets on the ball and releases a new driver in time for
> everyone to test before Gutsy final (now that it has been voted that
> Compiz will be enabled by default). If they don't, I think Gutsy will
> end up looking very unstable to users unfamiliar with the underlying
> causes.
>
> I have this problem on my 7600GT-based system and it's getting annoying
> to switch window managers every time I want to run an OpenGL app. I do
> *not* hope the 'buntu maintainers build Xorg without patch 132 as a
> workaround though, as that completely removes all incentive for nVidia
> to fix the real problem.
>
> In answer to Sitsofe's ABI observation, I would think that nVidia would
> simply put an item in the release notes indicating that the newer driver
> is only for Xorg (insert version # / patch level here) and later. It
> would be up to the repackagers to set dependencies for each version to
> their related Xorg packages.
>
> -J
>
>

[Bryan Haskins (bryan-h)]

You miss the point... if we were to work around it on our end it
wouldn't be a matter of having a new nvidia driver package, with as much
as we can do it has *nothing* to do with the nvidia driver (As said,
with as much as we can do, it is a nvidia problem) The only multi
package solution would to have xserver-xorg-mobile or something and the
mainline not having the patch. Which is only a shortterm fix, as this
patch is now upstream.

ChrisC wrote:
> making compiz enabled by default with this issue *regardless* of blame
> would be disastrous and could seriously dent efforts to correct bug #1
> it could even mean Ubuntu becoming a minor bit player of distros...
>
> Is this *defiantly* an nvidia bug, are people really sure that there isnt
> a bug with the clipping patch for xorg?
>
> Can the clipping patch not be altered to take into account nvidia
> drivers?
>
> theres a legacy nvidia an open source nvidia an older nvidia and
> an nividia-glx-new driver why not an nvidia-mobile driver too :o)
>
> enabling compiz by default with this bug could kill Ubuntu.
> This needs sorting *well* before November October is only
> a few weeks away...
>
> 3vi1 wrote:
>
>> I hope nVidia gets on the ball and releases a new driver in time for
>> everyone to test before Gutsy final (now that it has been voted that
>> Compiz will be enabled by default). If they don't, I think Gutsy will
>> end up looking very unstable to users unfamiliar with the underlying
>> causes.
>>
>> I have this problem on my 7600GT-based system and it's getting annoying
>> to switch window managers every time I want to run an OpenGL app. I do
>> *not* hope the 'buntu maintainers build Xorg without patch 132 as a
>> workaround though, as that completely removes all incentive for nVidia
>> to fix the real problem.
>>
>> In answer to Sitsofe's ABI observation, I would think that nVidia would
>> simply put an item in the release notes indicating that the newer driver
>> is only for Xorg (insert version # / patch level here) and later. It
>> would be up to the repackagers to set dependencies for each version to
>> their related Xorg packages.
>>
>> -J
>>
>>
>>
>
>

[wgscott (wgscott)]

Even without Compiz (or Beryl), the same problem arises if you turn
desktop effects compositing on (drop shadow on windows and so forth).

May I humbly suggest the offending patch simply be removed?

ChrisC wrote:
> making compiz enabled by default with this issue *regardless* of blame
> would be disastrous and could seriously dent efforts to correct bug #1
> it could even mean Ubuntu becoming a minor bit player of distros...
>
> Is this *defiantly* an nvidia bug, are people really sure that there isnt
> a bug with the clipping patch for xorg?
>
> Can the clipping patch not be altered to take into account nvidia
> drivers?
>
> theres a legacy nvidia an open source nvidia an older nvidia and
> an nividia-glx-new driver why not an nvidia-mobile driver too :o)
>
> enabling compiz by default with this bug could kill Ubuntu.
> This needs sorting *well* before November October is only
> a few weeks away...
>
> 3vi1 wrote:
>> I hope nVidia gets on the ball and releases a new driver in time for
>> everyone to test before Gutsy final (now that it has been voted that
>> Compiz will be enabled by default). If they don't, I think Gutsy will
>> end up looking very unstable to users unfamiliar with the underlying
>> causes.
>>
>> I have this problem on my 7600GT-based system and it's getting annoying
>> to switch window managers every time I want to run an OpenGL app. I do
>> *not* hope the 'buntu maintainers build Xorg without patch 132 as a
>> workaround though, as that completely removes all incentive for nVidia
>> to fix the real problem.
>>
>> In answer to Sitsofe's ABI observation, I would think that nVidia would
>> simply put an item in the release notes indicating that the newer driver
>> is only for Xorg (insert version # / patch level here) and later. It
>> would be up to the repackagers to set dependencies for each version to
>> their related Xorg packages.
>>
>> -J
>>
>>
>
> --
> [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 the bug.
>

[Kees Cook (kees)]

Adjusting the 132 patch to not re-order the structure while maintaining the logic seems to fix the crash for me. Can other people test this? I'd want to make sure the UME folks are okay too. (This build should be available on my PPA shortly).

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

1. NVidia will fix this with the new driver
2. The new driver will not make gutys
3. We need some sort of workaround
4. Having two xorg-server is I think a whole lot of work for the dev people (but ask them)
5. Here's a solution:

  - add a patch to make the noclipping thingie optional. Turn it into some sort sort of temporary xorg.conf setting.
  - make restricted drives manager set that setting automatically when installing the nvidia-driver

But then again, the final word will (and should) be from the xorg expert packagers.
Is such a workaround more feasilable? What does the specific patch do? Is it something we can turn of at run-time or does it have to be a compile time choice?

[Bryan Haskins (bryan-h)]

What you describe *is* compiz fusion. And it's not that simple, first
it's something we added in to fix another issue, second realistically
it's nvidia at fault... Do I condone us taking the highroad and leaving
it in so nvidia will fix it's issue... I'm torn. I don't think they'll
learn anything, but at the same time we shouldn't hack alternate fixes
for their blunder. This is an upstream patch now, they have to get their
blob to work with it or it simply... well won't work.

wgscott wrote:
> Even without Compiz (or Beryl), the same problem arises if you turn
> desktop effects compositing on (drop shadow on windows and so forth).
>
> May I humbly suggest the offending patch simply be removed?
>
>
> ChrisC wrote:
>
>> making compiz enabled by default with this issue *regardless* of blame
>> would be disastrous and could seriously dent efforts to correct bug #1
>> it could even mean Ubuntu becoming a minor bit player of distros...
>>
>> Is this *defiantly* an nvidia bug, are people really sure that there isnt
>> a bug with the clipping patch for xorg?
>>
>> Can the clipping patch not be altered to take into account nvidia
>> drivers?
>>
>> theres a legacy nvidia an open source nvidia an older nvidia and
>> an nividia-glx-new driver why not an nvidia-mobile driver too :o)
>>
>> enabling compiz by default with this bug could kill Ubuntu.
>> This needs sorting *well* before November October is only
>> a few weeks away...
>>
>> 3vi1 wrote:
>>
>>> I hope nVidia gets on the ball and releases a new driver in time for
>>> everyone to test before Gutsy final (now that it has been voted that
>>> Compiz will be enabled by default). If they don't, I think Gutsy will
>>> end up looking very unstable to users unfamiliar with the underlying
>>> causes.
>>>
>>> I have this problem on my 7600GT-based system and it's getting annoying
>>> to switch window managers every time I want to run an OpenGL app. I do
>>> *not* hope the 'buntu maintainers build Xorg without patch 132 as a
>>> workaround though, as that completely removes all incentive for nVidia
>>> to fix the real problem.
>>>
>>> In answer to Sitsofe's ABI observation, I would think that nVidia would
>>> simply put an item in the release notes indicating that the newer driver
>>> is only for Xorg (insert version # / patch level here) and later. It
>>> would be up to the repackagers to set dependencies for each version to
>>> their related Xorg packages.
>>>
>>> -J
>>>
>>>
>>>
>> --
>> [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 the bug.
>>
>>
>
>

[wgscott (wgscott)]

OK. I do understand there is a reason for not making the patch, and for
me at least, my linux system is primarily for scientific computations, and
the eye candy is completely gratuitous. But this is also why my preferred
platform is and remains Apple's OS X. I don't have to devote lots of time
and effort to sys administration, like I do with Linux. (I run an academic
scientific research group and have to do most of my own administration.)
I chose Ubuntu because of its comparative simplicity and ease of use, (and
because I was already familiar with the debian package management system
as a maintainer of debian packages for OS X via the Fink project). But it
is hardly seemless, and although I have been using it from the beginning,
more than half of the upgrades have had "show-stopper" glitches. I
realize that this is not Ubuntu's fault, but the bug has been around at
least since January on Fedora Core, according to some of my colleagues, so
it is clear Nvidia is not going to wiggle their collective behinds too
much to fix this.

OS X just works.
Ubuntu is 100% free if your time is of no value.

Bryan Haskins wrote:
> What you describe *is* compiz fusion. And it's not that simple, first
> it's something we added in to fix another issue, second realistically
> it's nvidia at fault... Do I condone us taking the highroad and leaving
> it in so nvidia will fix it's issue... I'm torn. I don't think they'll
> learn anything, but at the same time we shouldn't hack alternate fixes
> for their blunder. This is an upstream patch now, they have to get their
> blob to work with it or it simply... well won't work.
>
> wgscott wrote:
>> Even without Compiz (or Beryl), the same problem arises if you turn
>> desktop effects compositing on (drop shadow on windows and so forth).
>>
>> May I humbly suggest the offending patch simply be removed?
>>
>>
>> ChrisC wrote:
>>
>>> making compiz enabled by default with this issue *regardless* of blame
>>> would be disastrous and could seriously dent efforts to correct bug #1
>>> it could even mean Ubuntu becoming a minor bit player of distros...
>>>
>>> Is this *defiantly* an nvidia bug, are people really sure that there
>>> isnt
>>> a bug with the clipping patch for xorg?
>>>
>>> Can the clipping patch not be altered to take into account nvidia
>>> drivers?
>>>
>>> theres a legacy nvidia an open source nvidia an older nvidia and
>>> an nividia-glx-new driver why not an nvidia-mobile driver too :o)
>>>
>>> enabling compiz by default with this bug could kill Ubuntu.
>>> This needs sorting *well* before November October is only
>>> a few weeks away...
>>>
>>> 3vi1 wrote:
>>>
>>>> I hope nVidia gets on the ball and releases a new driver in time for
>>>> everyone to test before Gutsy final (now that it has been voted that
>>>> Compiz will be enabled by default). If they don't, I think Gutsy
>>>> will
>>>> end up looking very unstable to users unfamiliar with the underlying
>>>> causes.
>>>>
>>>> I have this problem on my 7600GT-based system and it's getting
>>>> annoying
>>>> to switch window managers every time I want to run an OpenGL app. I
>>>> do
>>>> *not* hope the 'buntu maintainers build Xorg without patch 132 a...

[Ryan Budney (delooper)]

Cool. I had been fighting with this bug for the past week and finally stumbled across this bug report. To me it makes perfect sense not to build a work around but to wait for a new nvidia driver. Does anyone know what the timeline might be on this corrected video driver?

[Kees Cook (kees)]

Please try builds for xorg-server here:
http://ppa.launchpad.net/keescook/ubuntu/

[IM.tehk (im-tehk)]

What work would be needed if the offending patch was placed in an
alternative, as mentioned before, xorg mobile package? I imagine it will
not be easy, but I guess it will save alot of people hassle in the long
run. The main thing I am enjoying about gutsy is that I no longer need
to deal with long tutorials to install Compiz/Beryl. This issue, if it
is not 'fixed', will find a place stickied in the How To section of the
ubuntu forums. This maybe Nvidias issue, but I suspect the user base
will not care who's issue it is. Ubuntu has used plenty of workarounds
to cater to problems that sit in other peoples court.

wgscott:Ubuntu would work just as well if they had to develop for only
14 distinct hardware situations like apple.

[wgscott (wgscott)]

On Fri, 14 Sep 2007 02:41:46 -0000
Kees Cook <email address hidden> wrote:

     Please try builds for xorg-server here:
     http://ppa.launchpad.net/keescook/ubuntu/

This works flawlessly (testing with Beryl that I compiled from source code I still had).

Thanks!!

I installed xserver-xorg-core_1.3.0.0.dfsg-12ubuntu5~ppa1_i386.deb with dpkg -i

[ChrisC (chris-chris-camacho-deactivatedaccount)]

I also installed

xserver-xorg-core_1.3.0.0.dfsg-12ubuntu5~ppa1_i386.deb

which works fine with compiz and blender running at the same time

however glxgears and other apps stutter and pause randomly
but work fine without compiz

Great work finding the xorg bug, but compiz still has a ways to
go before its release ready....

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

I've just tried the same patch. GLXGears Works. No Stutter either.
We love you Kees Cook.

So now we just need confirmation from _non_ nvidia users and ubuntu-mobile users.
But I doubt they visit this bug-report.. anyone got any bright ideas to extend the testing so this can get into gutsy on time?

@ChrisC what is your redirect fullscreen window setting?

[ChrisC (chris-chris-camacho-deactivatedaccount)]

Ralf Nieuwenhuijsen wrote:
> I've just tried the same patch. GLXGears Works. No Stutter either.
> We love you Kees Cook.
>
> So now we just need confirmation from _non_ nvidia users and ubuntu-mobile users.
> But I doubt they visit this bug-report.. anyone got any bright ideas to extend the testing so this can get into gutsy on time?
>
> @ChrisC what is your redirect fullscreen window setting?
>
>
not sure what you mean by "fullscreen window setting" but it stutters in
windowed mode too
can you give me the exact setting and which file its in ie

Option "RenderAccel" "True"
in the Section "Screen" of xorg.conf

[ChrisC (chris-chris-camacho-deactivatedaccount)]

I just noticed theres this you can put in the screens section of xorg.conf

Option "DisableGLXRootClipping" "true"

could someone whos not using the xorg without clipping patch package
(xserver-xorg-core_1.3.0.0.dfsg-12ubuntu5~ppa1_i386.deb)

see if this has any baring?

[3vi1 (launchpad-net-eternaldusk)]

>> Option "DisableGLXRootClipping" "true"

Tried. It makes no difference in that X still crashes when running glxgears on Compiz.

Also, when not using Compiz, it makes glxgears run about 10x slower. :(

I really don't think any configuration change is going to make a difference, if the problem is truely caused by incompatible ABIs.

[Duncan Lithgow (duncan-lithgow)]

>> Option "DisableGLXRootClipping" "true"

I've also just tried this and have the same behaviour as 3vi1 on a GeForce Go 7400

[Kees Cook (kees)]

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?

[Duncan Lithgow (duncan-lithgow)]

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... :)

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

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.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

@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 ..

[C Pirnat (histoplasmosis)]

unsucbscribe

[C Pirnat (histoplasmosis)]

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.
>

[3vi1 (launchpad-net-eternaldusk)]

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.

[Kees Cook (kees)]

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

[C Pirnat (histoplasmosis)]

unsubscribe

[Duncan Lithgow (duncan-lithgow)]

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.

[Duncan Lithgow (duncan-lithgow)]

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.

[Bryan Haskins (bryan-h)]

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
>
>

[David Megginson (david-megginson)]

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.

[Duncan Lithgow (duncan-lithgow)]

"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.

[Richard Ayotte (rich-ayotte)]

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.

[ChrisC (chris-chris-camacho-deactivatedaccount)]

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.
>
>

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

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

[Bryan Haskins (bryan-h)]

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.
>
>

[Kristoffer Lundén (kristoffer-lunden)]

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?

[David Megginson (david-megginson)]

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

[Bryan Haskins (bryan-h)]

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.
>>
>>
>>
>
>

[Bryan Haskins (bryan-h)]

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?
>
>

[Bryan Haskins (bryan-h)]

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
>
>

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

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.

[Bryan Haskins (bryan-h)]

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.
>
>

[ChrisC (chris-chris-camacho-deactivatedaccount)]

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.
>
>

[Bryan Haskins (bryan-h)]

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.
>>
>>
>>
>
>

[David Megginson (david-megginson)]

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

[David Megginson (david-megginson)]

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

[Bryan Haskins (bryan-h)]

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
>
>

[sam tygier (samtygier)]

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

[Richard Ayotte (rich-ayotte)]

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

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

[Ryan Budney (delooper)]

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...

[Bryce Harrington (bryce)]

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

[Bryce Harrington (bryce)]

(Not an l-r-m issue really)

[Re Alvarez (re-alvz)]

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

[Kees Cook (kees)]

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

[Re Alvarez (re-alvz)]

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

[David Megginson (david-megginson)]

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

[Re Alvarez (re-alvz)]

@David

Yes only with Compiz...