Bug 35194 - [r600g] Evergreen - failed to map bo
Summary: [r600g] Evergreen - failed to map bo
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-10 22:12 UTC by Rubén Fernández
Modified: 2011-05-13 16:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
output generated with MESA_GLSL=dump (924.94 KB, application/gzip)
2011-03-10 22:12 UTC, Rubén Fernández
Details
Patch for wine that leaves the r600 driver a little more address space (414 bytes, patch)
2011-04-04 22:50 UTC, Rubén Fernández
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Rubén Fernández 2011-03-10 22:12:54 UTC
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
Comment 1 Jussi Saarinen 2011-03-16 14:28:23 UTC
(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
Comment 2 Jussi Saarinen 2011-03-16 14:30:17 UTC
(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
Comment 3 Rubén Fernández 2011-04-04 22:48:23 UTC
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.
Comment 4 Rubén Fernández 2011-04-04 22:50:00 UTC
Created attachment 45262 [details] [review]
Patch for wine that leaves the r600 driver a little more address space
Comment 5 Marek Olšák 2011-04-05 06:00:50 UTC
I think this should be fixed in r600g instead, e.g. tiled textures never need to be mapped.
Comment 6 Rubén Fernández 2011-04-05 12:21:16 UTC
(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.
Comment 7 Rubén Fernández 2011-05-06 11:34:52 UTC
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.
Comment 8 Marek Olšák 2011-05-06 11:53:38 UTC
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.
Comment 9 Rubén Fernández 2011-05-13 16:28:46 UTC
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.