After the great work of Maciej doom3 now starts fine. However after about 1 minute of play the game trigger this: *********************************WARN_ONCE********************************* File radeon_dma.c function radeonReleaseDmaRegions line 348 Leaking dma buffer object! *************************************************************************** I am using current mesa_7_7_branch + the "radeon_dma.c function radeonReleaseDmaRegions line 348" fix from mesa_7_6_branch (it crashes after the WARN_ONCE without this one). Also using standard Ubuntu 2.6.31-14.48 kernel without KMS and latest libdrm git including libdrm_radeon. GL_RENDERER = Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX/SSE2 TCL
(In reply to comment #0) > After the great work of Maciej doom3 now starts fine. However after about 1 > minute of play the game trigger this: > > *********************************WARN_ONCE********************************* > File radeon_dma.c function radeonReleaseDmaRegions line 348 > Leaking dma buffer object! > *************************************************************************** > > I am using current mesa_7_7_branch + the "radeon_dma.c function > radeonReleaseDmaRegions line 348" fix from mesa_7_6_branch (it crashes after > the WARN_ONCE without this one). Does it work without that "fix" for the 7.6 branch?
> Does it work without that "fix" for the 7.6 branch? No, with a clean clone of 7.7 branch it asserts in a similar way to bug #24131 (see below). Apparently the "Leaking dma buffer object!" and the "Assertion `bo_legacy->is_pending <= bo->cref' failed." issues are related, and the commit: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_6_branch&id=13b5a624b1899c457279907d58046dfb3c95addc only hide the real problem, and make new issues appear: https://bugs.launchpad.net/bugs/459961 *********************************WARN_ONCE********************************* File radeon_dma.c function radeonReleaseDmaRegions line 348 Leaking dma buffer object! *************************************************************************** doom.x86: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed. signal caught: Aborted si_code -6 Trying to exit gracefully.. --------- Game Map Shutdown ---------- -------------------------------------- Shutting down sound hardware ----------- Alsa Shutdown ------------ close pcm dlclose -------------------------------------- idRenderSystem::Shutdown() doom.x86: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed. double fault Aborted, bailing out shutdown terminal support
I can confirm this bug. It happened to me playing to Freespace2 fs2_open 3.6.10 and using the latest community 3.6.10 MediaVPs (3D models and other game related media files). May be related to this, most times X locks hard and I must reset the computer. Just a note, retail Freespace2 mediaVP files do not trigger this (those?) bug(s). Freespace2 is a nice opensourced game. The project's website provides full source code and prebuild packages: http://scp.indiegames.us/ Running opensuse 11.1 (xorg 7.4, kernel 2.6.27.37) with Mesa 7.6, Radeon 9550 card.
I see this bug too when using a 3D application (e.g. playing something in Wine) with the following system: GPU: R300 Kernel: 2.6.32.8 X.org: 1.7.4 Mesa: 7.6.1 Radeon driver: 6.12.4 + commits up to 712ac98a Essentially Debian Testing except the Kernel (self-built) and the radeon driver (from Unstable, because it fixes <http://bugs.debian.org/565506>). Something I've noticed, that I see quite often (when stopping kdm or when I run glxinfo) a lot of messages like „glxinfo:5129 freeing invalid memtype e0102000-e0112000“ (this is one I triggered with glxinfo, the ones I see when stopping kdm are similar except the glxinfo part is then replaced by kdm). I don't know, if this might be related.
With the advent of 2.6.33(.1) I've switched to KMS and since then I can't reproduce this problem anymore (at least not so far).
Closing since r300 classic is unsupported and it works fine with r300g.
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.