Before reporting upstream, we probably have to try their newest version. In order to get at all started with that code I first built the Ubuntu source.
The Maverick debian package builds mesa obviously in 9 configurations mesa-7.9~git20100924/build/osmesa32-static/config.status mesa-7.9~git20100924/build/swx11+glu/config.status mesa-7.9~git20100924/build/osmesa/config.status mesa-7.9~git20100924/build/osmesa16-static/config.status mesa-7.9~git20100924/build/osmesa32/config.status mesa-7.9~git20100924/build/swx11+glu-static/config.status mesa-7.9~git20100924/build/osmesa16/config.status mesa-7.9~git20100924/build/dri/config.status mesa-7.9~git20100924/build/osmesa-static/config.status I have really no clue what they are all about, so I checked what glxgears uses from the mesa source package. There are 3 libraries: /usr/lib/mesa/libGL.so.1.2: Package: libgl1-mesa-glx Source: mesa /usr/lib/libGLU.so.1.3.070900: Package: libglu1-mesa Source: mesa /usr/lib/dri/r200_dri.so: Package: libgl1-mesa-dri Source: mesa libGL.so.1.2 is built in the dri configuration. libGLU.so.1.3.070900 is built in the wx11+glu configuration. r200_dri.so is built in the dri configuration. So I just guessed that the dri configuration might the relevant one here and built the newest mesa as follows: git clone git://anongit.freedesktop.org/mesa/mesa cd mesa ./autogen.sh '--build=i686-linux-gnu' '--with-driver=dri' '--with-dri-drivers=r200' '--with-egl-displays=x11 drm' '--enable-glx-tls' '--with-state-trackers=egl,glx,dri,vega' '--enable-gles-overlay' '--enable-gles1' '--enable-gles2' '--enable-driglx-direct' '--disable-glu' '--disable-glut' '--disable-glw' '--enable-debug' 'CFLAGS=-Wall -g -O0' '--with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri' 'build_alias=i686-linux-gnu' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS=' 'CXXFLAGS=-g -O0' make cd lib LIBGL_DRIVERS_PATH=. glxgears Mesa: Mesa 7.10-devel DEBUG build Oct 8 2010 11:17:51 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 253 frames in 5.0 seconds = 50.547 FPS 251 frames in 5.0 seconds = 50.118 FPS glxgears: ../../radeon/radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed. Aborted (The assertion is sometimes hit immediately, sometimes first when resizing the window) My configuration options were some wild guessing merge of Maverick's mesa-7.9~git20100924/build/dri/config.status and the instructions given in https://bugs.freedesktop.org/show_bug.cgi?id=29066, together with the assumption that gallium is not applicable to r200. Not sure where the debugging info should be written. There was nothing in syslog. This is the call stack: #0 0x0012e416 in __kernel_vsyscall () #1 0x003bb941 in raise () from /lib/libc.so.6 #2 0x003bee42 in abort () from /lib/libc.so.6 #3 0x003b48e8 in __assert_fail () from /lib/libc.so.6 #4 0x00afc158 in ?? () from /lib/libdrm_radeon.so.1 #5 0x00afcd80 in radeon_cs_write_reloc () from /lib/libdrm_radeon.so.1 #6 0x0071de59 in ctx_emit_cs (ctx=0x8072a70, atom=0x806dc30) at r200_state_init.c:575 #7 0x0074c3d2 in radeon_emit_atom (radeon=0x806d730, atom=0x806dc30) at radeon_common.c:1032 #8 0x0074c512 in radeonEmitAtoms (radeon=0x806d730, emitAll=0 '\000') at radeon_common.c:1056 #9 0x0074c708 in radeonEmitState (radeon=0x806d730) at radeon_common.c:1099 #10 0x00726f36 in r200AllocEltsOpenEnded (rmesa=0x806d730, primitive=532, min_nr=6) at r200_cmdbuf.c:210 #11 0x0072cb96 in r200AllocElts (rmesa=0x806d730, nr=6) at r200_tcl.c:164 #12 0x0072d65d in tcl_render_tri_fan_verts (ctx=0x8072a70, start=0, count=4, flags=54) at ../../../../../src/mesa/tnl_dd/t_dd_dmatmp2.h:380 #13 0x0072e574 in r200EmitPrimitive (ctx=0x8072a70, first=0, last=4, flags=54) at r200_tcl.c:249 #14 0x0072f0f9 in r200_run_tcl_render (ctx=0x8072a70, stage=0x80c5158) at r200_tcl.c:562 #15 0x0086a0a1 in _tnl_run_pipeline (ctx=0x8072a70) at tnl/t_pipeline.c:153 ---Type <return> to continue, or q <return> to quit--- #16 0x0071ba76 in r200WrapRunPipeline (ctx=0x8072a70) at r200_state.c:2460 #17 0x0086b342 in _tnl_draw_prims (ctx=0x8072a70, arrays=0x80b35dc, prim=0xbffff0c0, nr_prims=1, ib=0x0, min_index=0, max_index=3) at tnl/t_draw.c:478 #18 0x0086b0af in _tnl_vbo_draw_prims (ctx=0x8072a70, arrays=0x80b35dc, prim=0xbffff0c0, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at tnl/t_draw.c:384 #19 0x0085dce4 in vbo_exec_DrawArrays (mode=6, start=0, count=4) at vbo/vbo_exec_array.c:526 #20 0x0085f292 in _mesa_DrawArrays (mode=6, first=0, count=4) at vbo/vbo_exec_array.c:1159 #21 0x008f64a9 in _mesa_meta_Clear (ctx=0x8072a70, buffers=18) at drivers/common/meta.c:1472 #22 0x0074d10d in radeonUserClear (ctx=0x8072a70, mask=18) at radeon_common.c:1332 #23 0x007151c3 in r200Clear (ctx=0x8072a70, mask=0) at r200_ioctl.c:249 #24 0x0078795c in _mesa_Clear (mask=16640) at main/clear.c:179 #25 0x080492db in ?? () #26 0x0804a882 in ?? () #27 0x003a7ce7 in __libc_start_main () from /lib/libc.so.6 #28 0x080490c1 in ?? () (that looks identical to the amd64 stack originally submitted by Daniel Richard G.) So the assertion happens actually in libdrm_radeon.so, although it's directly called from the new code built by me. Maybe we should check also with the newest version of libdrm_radeon.so ??? All input welcome, I'm just playing around here without really knowing what I'm doing. ** Bug watch added: freedesktop.org Bugzilla #29066 http://bugs.freedesktop.org/show_bug.cgi?id=29066 -- [R200] ../../radeon/radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed. https://bugs.launchpad.net/bugs/656100 You received this bug notification because you are a member of Ubuntu-X, which is subscribed to mesa in ubuntu. _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp