Created attachment 44337 [details] output generated with MESA_GLSL=dump The game "Back to the Future: the game" crashes at many points with the message: radeon_bo_fixed_map failed to map bo EE radeon_bo.c:120 radeon_bo - failed to map bo It usually happens at random moments, altough there are specific actions that trigger the crash reliably. It works correctly using llvmpipe. The "failed to map" message originates in the function "radeon_bo_fixed_map" in "mesa/src/gallium/winsys/r600/drm/radeon_bo.c", when doing a call to mmap; upon debugging, I found it fails with ENOMEM, despite having more than enough free RAM available at the time (it only allocates half a megabyte, and I had almost 1GB of free RAM at the moment of crashing) Upon further inspection, I found that, at the moment of the crash, the game had almost exactly 1 gigabyte of buffer objects mmap'd; could it have something to do with my card having 1GB of video RAM? seems unlikely, since mmap maps to system memory. Graphics Card: ATI Technologies Inc Juniper [Radeon HD 5750 Series] CPU: Intel Core Duo 1.8 Ghz, 2.5 GB RAM Linux kernel 2.6.37, libdrm 2.4.24 Latest Mesa git
(In reply to comment #0) > > The game "Back to the Future: the game" crashes at many points with > the message: > > radeon_bo_fixed_map failed to map bo > EE radeon_bo.c:120 radeon_bo - failed to map bo > I also have run into this same bug when running 3DMark 2001 SE in wine. Motherboard: Gigabyte MA790XT-UD4P Chipset: North Bridge AMD 790X / South Bridge AMD SB750 Processor: AMD Phenom II X3 720 Display adapter: Club 3D HD 4770 512MB (RV740) Display: HP Pavilion f1940 (1280x1024) Distribution: ArchLinux x86-64 (rolling release, up to date) Installed packages: kernel: 2.6.37.4-1 xorg-server: 1.9.4.901-1 xf86-video-ati: 6.14.0-2 xf86-input-evdev: 2.6.0-2 libdrm: 2.4.23-2 mesa: 7.10.1-1 ati-dri: 7.10.1-1 libgl: 7.10.1-1
(In reply to comment #1) > (In reply to comment #0) > > > > The game "Back to the Future: the game" crashes at many points with > > the message: > > > > radeon_bo_fixed_map failed to map bo > > EE radeon_bo.c:120 radeon_bo - failed to map bo > > > > I also have run into this same bug when running 3DMark 2001 SE in wine. > Sorry, I forgot to add this: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV740 OpenGL version string: 2.1 Mesa 7.10.1 OpenGL shading language version string: 1.20
The problem seems to be related to the way wine manages memory; wine reserves the top 2GB of the addressing space to itself on startup, leaving only 2GB for everything else (including mesa and the userspace radeon driver); it seems we aren't running out of memory, but out of addressing space. For instance, patching wine to make it use only the top 1GB of address space mitigates the problem (but doesn't make it go away) - the "failed to map bo" crashes occur with much lower frequency. This might even be a wine bug - altough it doesn't occur with LLVMPIPE rendering, or with r300, or with a proprietary driver. I'll attach the wine patch, just for reference.
Created attachment 45262 [details] [review] Patch for wine that leaves the r600 driver a little more address space
I think this should be fixed in r600g instead, e.g. tiled textures never need to be mapped.
(In reply to comment #5) > I think this should be fixed in r600g instead, e.g. tiled textures never need > to be mapped. Using gallium with the latest git (commit de579a16298e29358fec08bd7cfe3e505674705a, plus kernel 2.6.38.2) the bug still happens. Using R600_TILING=1 makes the textures look all wrong, and yet the bug doesn't go away.
Setting R600_ENABLE_S3TC=1, the bug goes away completely. I didn't try it before because the game rendered correctly without it, so I thought it didn't use compressed textures. Maybe it has a fallback that decompresses the textures if S3TC isn't supported, at the cost of consuming lots more memory? Or maybe the fallback triggers the bug, and not the normal code. Jussi, I recommend you try enabling S3TC and see if you still get the bug. If not, and since S3TC will become the default eventually, I'd call this bug solved.
Some distributions can't enable S3TC. The fact it looks fixed with S3TC might be that the compression ratio is 1:8 or 1:4, depending on the format, so it saves quite a lot of memory.
With the recent batch of commits from Dave Airlie (starting with 5e15497452cf3e4d2fc76fdc6ed8113d0891b467), the bug dissapears completely, even without enabling S3TC. It seems the problem was simply that the driver was mapping too many buffers unnecessarily; now none of the Telltale games that had the bug crash, no matter for how long I leave them running, with or without S3TC and with or without tiling. Don't know about Jussi, but as far as I can tell, this issue is fixed.
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.