Bug 8348 - [MESA 6.5.1] PPracer causes r300 driver to assert failure
[MESA 6.5.1] PPracer causes r300 driver to assert failure
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300
unspecified
Other Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-18 19:00 UTC by Shawn Starr
Modified: 2006-11-22 10:11 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shawn Starr 2006-09-18 19:00:05 UTC
Running ppracer for a little while, while playing it aborts with this in a 
console.

ppracer: r300_ioctl.c:683: r300AllocDmaRegion: Assertion 
`rmesa->dma.current.ptr <= rmesa->dma.current.end' failed.

This is reproducible.
Comment 1 Shawn Starr 2006-09-18 19:05:06 UTC
More information:

[drm] Initialized radeon 1.25.0 20060524 on minor 0:

[102234.244000] mtrr: 0xe0000000,0x8000000 overlaps existing 
0xe0000000,0x4000000
[102234.244000] mtrr: 0xe0000000,0x8000000 overlaps existing 
0xe0000000,0x4000000
[102234.244000] mtrr: 0xe0000000,0x8000000 overlaps existing 
0xe0000000,0x4000000
[102234.244000] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
[102234.244000] agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
[102234.248000] agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
[102234.544000] [drm] Setting GART location based on new memory map
[102234.544000] [drm] Loading R300 Microcode
[102234.544000] [drm] writeback test succeeded in 2 usecs

* libdrm 2.0.2
* Sept 16th snapshot of drm kernel drivers.
Comment 2 Panu Matilainen 2006-10-31 13:25:58 UTC
Me too, on FC6 (x86_64), easily reproducable here at least on "Dead Mans Drop"
track but seen on various other tracks as well:

ppracer: r300_ioctl.c:683: r300AllocDmaRegion: Assertion `rmesa->dma.current.ptr
<= rmesa->dma.current.end' failed.
Aborted

Driver version is xorg-x11-drv-ati-6.6.2-4.fc6
Comment 3 Jerome Glisse 2006-11-01 16:30:44 UTC
The bug lie in radeon_vtmx code, more specificly in DrawElements
and DrawRangeElements. Basicly glDrawElements and glDrawRangeElements
let you draw a number of (count) elements, and you give an array of
indices in the array of vertices. Thus you have to upload max - min
vertex where max is the highest index in the indices array and min
is the lowest index in the indices array. The (max - min) value isn't
checked against RADEON_BUFFER_SIZE thus the DrawElements might ask
for DMA region which can't be allocated.

I don't see any easy fix to that, this likely need a bunch of corner
case test. So i think we should avoid loosing time fixing this, we
will get a better solution when i (or any other person :)) port the
r300 driver to the shiny new TTM infrastructure and then get benefits
from the generic VBO handling they will come with this =).

As a workaround i suggest to disable vtmx code, you could do that by
commenting out #define RADEON_VTXFMT_A in r300_context.h

A side note: this bug is triggered by ppracer because it seems that
ppracer is growing its vertices array with new vertex while playing
the game.
Comment 4 Jerome Glisse 2006-11-02 07:46:03 UTC
In fact after looking at VBO branch we will need to look at
that thus i reopen this one and will make the change in VBO
branch which should be merged in a couple of days.
Comment 5 Jerome Glisse 2006-11-02 12:17:29 UTC
If you have enought GART memory you shouldn't see the bug anymore
with current cvs. I still want to fix functions which are allocating
memory so they can fail gracefully and fallback in case the request
doesn't fit in the memory.
Comment 6 Jerome Glisse 2006-11-22 10:11:31 UTC
Will open a another bug for a real clean solution to
indexed vertex array submission and size checking.