freeze when setting GARTSize to "64"

tested on xorg driver version 6.7.194:

when setting GARTSize to "64" to avoid memory problems..... memory problems seem to occur :
with "heavy" 3D applications, the display gets corrupt and X hangs, without being able to restart it.

I attach the full gdb log obtained via SSH.

Created an attachment (id=11804)
the gdb log

Created an attachment (id=11805)
the xorg log

Created an attachment (id=11806)
a screenshot just before freeze

here is a screenshot of a pathologic 3D rendering : holes are clearly visible, in the form of "stripes" and corrupted triangles. This artifact is a warning, and if I continue to use the application, X hangs.

Created an attachment (id=11807)
xorg.conf

Looking at the code, I think PCIe cards need a corresponding Option "PCIAPERSize" "64". The driver should probably handle this more sanely by default...

<Quote>
Looking at the code, I think PCIe cards need a corresponding Option
"PCIAPERSize" "64". The driver should probably handle this more sanely by
default... </quote>

thanks for the tip... I replaced GARTSize with PCIAPERSize, and X does not hang anymore, but the memory problem is still here :

*********************************WARN_ONCE*********************************
File r300_mem.c function r300_mem_alloc line 225
Ran out of GART memory (for 1048576)!
Please consider adjusting GARTSize option.
***************************************************************************

this does not happen on my other ati Radeon Mobility 9600 (AGP). I also tried with both options simultaneously, with no luck.

(In reply to comment #6)
> this does not happen on my other ati Radeon Mobility 9600 (AGP).

Because that's an AGP card.

> I also tried with both options simultaneously,

That's what I meant by 'corresponding', sorry if it wasn't clear.

> with no luck.

Which of the two problems occurs then? Please attach the log file for this case as well.

with both options enabled, I get this message :

*********************************WARN_ONCE*********************************
File r300_mem.c function r300_mem_alloc line 225
Ran out of GART memory (for 1048576)!
Please consider adjusting GARTSize option.
***************************************************************************

using GARTSize usually removes it, no?

sometimes I get:

libGL error: drmMap of framebuffer failed (Cannot allocate memory)
libGL error: reverting to (slow) indirect rendering
but the programm continues

sometimes I get:
"Error: Could not get dma buffer... exiting"
and the programm crashes

Xorg log does not pop any error message, but I join it anyway...

Created an attachment (id=11839)
the xorg.log with both options

(In reply to comment #8)
> with both options enabled, I get this message :

Weird, the log looks fine.

> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
> libGL error: reverting to (slow) indirect rendering
> but the programm continues
>
> sometimes I get:
> "Error: Could not get dma buffer... exiting"
> and the programm crashes

And these don't happen without the options?

Does using just Option "GARTSize" "32" work?

>
> And these don't happen without the options?
>
of course the messages and crashes happen without the options :)
I thought the options were designed to solve these problems, no?

> Does using just Option "GARTSize" "32" work?
>
same thing.

I tried valgrind on the programm but it hanged my X...
What can I do more to investigate this issue?

(In reply to comment #11)
> I thought the options were designed to solve these problems, no?

Just 'Ran out of GART memory', not the others.

> > Does using just Option "GARTSize" "32" work?
> >
> same thing.

Meaning the above error?

> What can I do more to investigate this issue?

Log in remotely and run the program in gdb or add debugging output to find out why the error occurs.

(In reply to comment #12)
> (In reply to comment #11)
> > I thought the options were designed to solve these problems, no?
>
> Just 'Ran out of GART memory', not the others.

So, there is still something wrong as the "Please consider adjusting GARTSize option." is still present.

>
>
> > > Does using just Option "GARTSize" "32" work?
> > >
> > same thing.
>
> Meaning the above error?

nothing changes : I still get the warning about GARTSize and the program stills crashes after a while (but works fine on other hardware)

>
>
> > What can I do more to investigate this issue?
>
> Log in remotely and run the program in gdb or add debugging output to find out
> why the error occurs.
>

Sorry, I am not well trained for gdb. I tried it, but the only message I got was : Program exited with code 0377 (I join the log. My program is called MAT). If you have any suggestion for commands, I'm in.

To sum up things a little bit :
- My Computer does not hang anymore (good :) )
- But the PCIAPERSize does note solve memory problems

Created an attachment (id=11840)
the gdb output for the MAT programm

(In reply to comment #13)
> Sorry, I am not well trained for gdb. I tried it, but the only message I got
> was : Program exited with code 0377

You need to set breakpoints in interesting places.

> - But the PCIAPERSize does note solve memory problems

It's not supposed to on its own, it just makes sure the GART table is actually large enough for the corresponding Option "GARTSize".

(In reply to comment #15)
> (In reply to comment #13)
> > Sorry, I am not well trained for gdb. I tried it, but the only message I got
> > was : Program exited with code 0377
>
> You need to set breakpoints in interesting places.

I'm not sure I'm able to do that correctly. My program uses the Visualization Tool Kit (VTK), and OpenGL commands are invoked inside the library, So the breakpoints won't tell many things, I suppose.

(In reply to comment #16)
> My program uses the Visualization Tool Kit (VTK), and OpenGL commands are
> invoked inside the library, So the breakpoints won't tell many things, I
> suppose.

That shouldn't matter for r300_dri.so, where the interesting places should be for this, e.g. where it generates the error about insufficient GART memory.

(In reply to comment #17)
> (In reply to comment #16)
> > My program uses the Visualization Tool Kit (VTK), and OpenGL commands are
> > invoked inside the library, So the breakpoints won't tell many things, I
> > suppose.
>
> That shouldn't matter for r300_dri.so, where the interesting places should be
> for this, e.g. where it generates the error about insufficient GART memory.
>

OK. When I find what instruction in my programm causes the message (or crash), what command(s) should I type to give you the relevant bits?

Sorry to turn this bug report into a newbie training session....