Hello,

I have more informations for you.

Reproductible: Always

Steps to reproduce:

* Launch neverball with the r300g driver and a rs690 graphics card
* Go to Options
* Set Textures to High
* Set Geometry to High
* Set Reflection to Yes*
* Click "Back"
* Press CAPS LOCK
* Enter CHEAT (when all the leters are typed, the Play menu changes to Cheat)
* You can again press CAPS LOCK
* Click on Cheat
* Click on Tour de force
* Click on 09. It's a race full of mirrors.

The Command Stream is rejected and Neverball segfaults.

*It seems that keeping Reflection to No also triggers the bug, but a bit later. The race is not loaded but I have to wait one more second to see Neverball crashing, also with a CS error :

[drm:r100_cs_packet_next_reloc] *ERROR* No packet3 for relocation for packet at 214.
[drm] ib[214]=0x000013C6
[drm] ib[215]=0x00000001
[drm:r100_packet3_load_vbpntr] *ERROR* No reloc for packet3 47
[drm] ib[209]=0xC0032F00
[drm] ib[210]=0x00000001
[drm] ib[211]=0x00001010
[drm] ib[212]=0x0004E040
[drm] ib[213]=0x00000000
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

GDB output when running Neverball:

I launched Neverball under GDB with "gdb neverball". The stderr line "radeon: The kernel rejected CS, see dmesg for more information." isn't printed, but GCC prints this :

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1a3bad8 in r300_emit_aos_swtcl (r300=0x7fed40, indexed=16 '\020') at r300_emit.c:847
847         OUT_CS_BUF_RELOC(r300->vbo, 0, r300_buffer(r300->vbo)->domain, 0);
(gdb) bt
#0  0x00007ffff1a3bad8 in r300_emit_aos_swtcl (r300=0x7fed40, indexed=16 '\020') at r300_emit.c:847
#1  0x00007ffff1a3f5c4 in r300_render_draw_elements (render=0x65acc0, indices=0x9adfd0, count=192)
    at r300_render.c:889
#2  0x00007ffff1bbe111 in vbuf_flush_vertices (stage=0xc75a70, flags=<value optimized out>)
    at draw/draw_pipe_vbuf.c:327
#3  vbuf_flush (stage=0xc75a70, flags=<value optimized out>) at draw/draw_pipe_vbuf.c:380
#4  0x00007ffff1bbaa6e in draw_pipeline_flush (draw=0x718480, flags=<value optimized out>) at draw/draw_pipe.c:346
#5  0x00007ffff1bb3e61 in draw_do_flush (draw=0x718480) at draw/draw_context.c:550
#6  draw_flush (draw=0x718480) at draw/draw_context.c:174
#7  0x00007ffff1a3e1da in r300_swtcl_draw_vbo (pipe=0x7fed40, info=0x7fffffffdb00) at r300_render.c:694
#8  0x00007ffff1b764fd in st_draw_vbo (ctx=0x978810, arrays=<value optimized out>, prims=0xc8aca4, nr_prims=1, 
    ib=0x0, index_bounds_valid=<value optimized out>, min_index=0, max_index=309) at state_tracker/st_draw.c:719
#9  0x00007ffff1b99bc9 in vbo_save_playback_vertex_list (ctx=0x978810, data=0x8223f8) at vbo/vbo_save_draw.c:287
#10 0x00007ffff1a8115a in ext_opcode_execute (ctx=0x978810, list=<value optimized out>) at main/dlist.c:533
#11 execute_list (ctx=0x978810, list=<value optimized out>) at main/dlist.c:6883
#12 0x00007ffff1a83bd2 in _mesa_CallList (list=744) at main/dlist.c:8140

I don't know if it's the same bug, but it is triggered at the same place.

I hope this helps you (and sorry for my English).

Hello,

I updated Mesa to 7dcb3050006a12c8afa44e436902b8a663855bc8, and the crash has changed. When run out of GDB, the same CS rejection arises. When in GDB, there is an other crash in r300_emit_aos_swtcl.

When I tried to run Neverball under GDB, it crashed when I clicked on the 09 race. GDB had the time to display three lines of informations, and then Xorg froze. I was able to switch to VT1 and to kill it.

These lines :

Program received signal SIGSEGV, Segmentation fault
r300_emit_aos_swtcl(r300=0x7265f0, indexed=16 '\020') at r300_emit.c: 847
847 OUT_CS(1 | (!indexed ? R300_VC_FORCE_PREFETCH : 0));
(gdb)

There is an assert at the line 845, in BEGIN_CS, but it was not thrown. I compiled Mesa with its default configure options, so I don't know if the asserts were enabled. Here is a command launched to compile one of the r300g objects :

gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/mesa/drivers/dri/r300/compiler -I../../../../src/gallium/winsys/drm/radeon/core -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -DHAVE_UDIS86 -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -I/usr/include  -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fomit-frame-pointer -fPIC r300_texture.c -o r300_texture.o

The emit_aos_swtcl crash has been fixed by commit     428dc6d7d2cf6a5da37a2ea7ce436cf521b009a2.

Do you still have any issue there?

Sorry, I don't know. I updated Mesa to the latest Git version and got a segfault when any OpenGL program starts.

The segfaults is in src/gallium/drivers/r300/r300_context.c:425 (r300_create_context). GDB said that the line 425 is segfaulting :

425 r300->cs = rws->cs_create(rws);

I explored the values of some variables, r300 is ok, rws is ok and rws->cs_create seems to contain an address in r300_dri.so. I don't know why it is segfaulting.

I will try to bisect Mesa to see when it happened, but I now have to disable GLX in my xorg.conf to have Xorg starting without segfaulting. I am unable to launch any GL program, so it will take some time. For now, the only commit I think can be responsible of this segfault is a508d2dddcc67d0f92cc36b9ed6f36a9bbfc579d (gallium: introduce get_shader_param (ALL DRIVERS CHANGED) (v3)). It adds an entry in r300screen, but I don't know if it is possible that it is related to my segfault.

try: git clean -fdx

and rebuild mesa.

It works ! Thank you very much, this bug is now solved for me.

OK, closing..