Bug 22742

Can you start the game from terminal and upload the output
(if it hits an assert or faults it will be printed there)
Additionally from ssh, could you attach the game with gdb when in hangs
and get a backtrace.

Mine asserts with 
prey-demo.x86: radeon_texture.c:856: migrate_image_to_miptree: Assertion `dstlvl->width == image->base.Width' failed.

Program received signal SIGABRT, Aborted.

(gdb) bt
#0  0xb7fff424 in __kernel_vsyscall ()
#1  0x448887c1 in raise () from /lib/libc.so.6
#2  0x4488a092 in abort () from /lib/libc.so.6
#3  0x448818ee in __assert_fail () from /lib/libc.so.6
#4  0xb61be6f6 in migrate_image_to_miptree (mt=0xb1c5f98, image=0xb198b30,
    face=0, level=1) at radeon_texture.c:856
#5  0xb61bed62 in radeon_validate_texture_miptree (ctx=0xadde880,
    texObj=0xb19aa90) at radeon_texture.c:973
#6  0xb61bcd65 in radeonMapTexture (ctx=0xadde880, texObj=0xb19aa90)
    at radeon_texture.c:162
#7  0xb61d236f in radeonSpanRenderStart (ctx=0xadde880) at radeon_span.c:509
#8  0xb630564c in swrast_render_start (ctx=0xadde880) at swrast/s_context.h:267
#9  0xb63056ee in read_color_image (ctx=0xadde880, x=0, y=0, type=5121,
    width=640, height=480) at swrast/s_texstore.c:80
#10 0xb63067f0 in _swrast_copy_texsubimage2d (ctx=0xadde880, target=3553,
    level=0, xoffset=0, yoffset=0, x=0, y=0, width=640, height=480)
    at swrast/s_texstore.c:511
#11 0xb626a6b4 in _mesa_CopyTexSubImage2D (target=3553, level=0, xoffset=0,
    yoffset=0, x=0, y=0, width=640, height=480) at main/teximage.c:3243
#12 0x080fb955 in strcpy ()
#13 0x0815e526 in strcpy ()
#14 0x0815f340 in strcpy ()
#15 0x08176f7c in strcpy ()
#16 0x0816644a in strcpy ()
#17 0x08133349 in strcpy ()
#18 0x0805dc1f in strcpy ()
#19 0x0805f61e in strcpy ()
#20 0x0805eff7 in strcpy ()
#21 0x082744ef in strcpy ()
#22 0x44873a66 in __libc_start_main () from /lib/libc.so.6
#23 0x0804b211 in strcpy ()

If you get different results I'll open a new bug for my system

Created attachment 27789 [details]
prey console output

prey does not assert for me, it only freezes. I'll attach the console output (redirected to a file) and a backtrace attaching gdb from ssh.

Created attachment 27790 [details]
prey backtrace

Can you compile with debugging information enabled to get a more useful backtrace?

Apart from that, you might want to play around with setting the RADEON_DEBUG environment variable. For possible settings of this variable, look for "debug_control" in http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/radeon/radeon_screen.c

This will probably create a shitload of output, but at least it can probably tell you whether the program is still sending OpenGL commands or not once it gets stuck.

Created attachment 27883 [details]
prey console output with DEBUG_CMDBUF defined to 1 and RADEON_DEBUG=all

(In reply to comment #4)
> Can you compile with debugging information enabled to get a more useful
> backtrace?

the attached backtrace was already obtained with mesa debugging information enabled, i.e. the default build.

> Apart from that, you might want to play around with setting the RADEON_DEBUG
> environment variable.

I am attaching the game console output after recompiling mesa with DEBUG_CMDBUF defined to 1 in radeon_common.c and the following command line: 
RADEON_DEBUG=all ./prey-demo > ~/prey-output.txt 2>&1

Mass version move, cvs -> git

Created attachment 30487 [details] [review]
workaround

Attached patch works around the problem.

I'm able to start a game with this, but after loading a level no textures are drawn (it might be both a driver or game bug) and the game is slow (because it's using glCopyTex[Sub]Image which isn't hardware accelerated yet).

> Attached patch works around the problem.
> 
> I'm able to start a game with this, but after loading a level no textures are
> drawn (it might be both a driver or game bug) and the game is slow (because
> it's using glCopyTex[Sub]Image which isn't hardware accelerated yet).

With the patch applied I get the same behaviour, which is also the same I got with mesa 7.5. Also the patch fixes bug #23710.

Thanks! 

It's fixed in current mesa_7_7_branch. Can you confirm?

(In reply to comment #9)
> It's fixed in current mesa_7_7_branch. Can you confirm?

Confirmed. Also confirmed that it renders properly only when libtxc_dxtn.so is available.