Bug 8348 - [MESA 6.5.1] PPracer causes r300 driver to assert failure
Summary: [MESA 6.5.1] PPracer causes r300 driver to assert failure
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
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.


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.