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.
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.
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
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.
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.
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.
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.