| Summary: | crash during (or at end) of map loading in ut2004 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | XoD <xoddark> |
| Component: | Drivers/Gallium/r600 | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
XoD
2011-01-25 12:08:49 UTC
If I add a sprintf before memcpy in r600_upload.c I was able to debug in r600_upload_buffer.
The call stack was :
#0 memcpy() at ../sysdeps/x86_64/memcpy.S:267
#1 fprintf() at /usr/include/bits/string3.h:52
#2 r600_upload_buffer() at r600_upload.c:109
#3 r600_upload_user_buffers() at r600_buffer.c:239
#4 evergreen_vertex_buffer_update() at evergreen_state.c:1372
#5 st_draw_vbo() at state_tracker/st_draw.c:712
...
Patch :
diff --git a/src/gallium/drivers/r600/r600_upload.c b/src/gallium/drivers/r600/r600_upload.c
index 44102ff..ba19185 100644
--- a/src/gallium/drivers/r600/r600_upload.c
+++ b/src/gallium/drivers/r600/r600_upload.c
@@ -103,7 +103,11 @@ int r600_upload_buffer(struct r600_upload *upload, unsigned offset,
}
in_ptr = in_buffer->user_buffer;
- memcpy(upload->ptr + upload->offset, (uint8_t *) in_ptr + offset, size);
+ uint8_t * ptr_src = (uint8_t *) upload->ptr + upload->offset;
+ uint8_t * ptr_dest = (uint8_t *) in_ptr + offset;
+ //R600_ERR("memcpy src %d dest %d size %d\n", ptr_src, ptr_dest, size);
+ fprintf(stdout, "memcpy src %p dest %p size %d\n", ptr_src, ptr_dest, size);
+ memcpy(ptr_src, ptr_dest, size);
*out_offset = upload->offset;
*out_size = upload->size;
*out_buffer = NULL;
Can you do me a favor an check what your UseVBO setting is? It's a config setting of the OpenGL renderer (check $HOME/.ut2004/System/UT2004.ini). I'm interested because I'm also experiencing crashes in ut04 (see bug #33172) with certain settings. With "UseVBO=True" I was be able to finish the loading. But my system has freeze when i have try to spawn my player character. I forgot to présise before : i have run test on a ATI Mobility Radeon HD 5730 (Evergreen). (In reply to comment #4) > If I haven't debbuggeur attach ut2004 terminate on a DBUS error (Signal SIGBUS) A bus error indicates something may have gone wrong in the kernel. Is there something interesting in dmesg or the kernel log file? (In reply to comment #4) > (In reply to comment #4) > > If I haven't debbuggeur attach ut2004 terminate on a DBUS error (Signal SIGBUS) > > A bus error indicates something may have gone wrong in the kernel. Is there > something interesting in dmesg or the kernel log file? I have not seen anything significant in the log. but with a 2.6.37 kernel with this patch from agd5f : http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-re-emit-full-context-state-for-evergr.patch ut2004 is killed by SIGBUS only in "very high"(the most hight level) texture detailed mode And crash isn't systematic, I haven't reproduce it with a debuggeur attach. (In reply to comment #5) > ut2004 is killed by SIGBUS only in "very high"(the most hight level) texture > detailed mode > And crash isn't systematic, I haven't reproduce it with a debuggeur attach. With last git version of mesa and r600g I can play with full detail at ut2004. Thank's All Was probably fixed by the same changes that also fixed bug #33172. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.