Peter,

This is just a very quick reply on the few minutes I have before leaving. 
I'm sure that someone else on the list may elaborate further and give you 
indications to what try next.

On 2002.04.25 02:02 Peter Andersson wrote:
> ...
> 
>>  - Copy the Xfree86.0.log to a safe place and post it here.
> 
> Its attatched to this email.

Nothing unusual here.

>> See if there is any application consuming all processor (top).
> 
> It seems that the X server hangs too since when i try to backtrace it 
> nothing happens even though only about 2% of the processor are used by 
> the system processes. And if i try to backtrace before i run glxgears 
> the X server locks until i have quit gdb..

It's ok if X stops responding, but you should be able to get a stack 
backtrace anyway. I'm not sure if you need to press Ctrl-C inside gdb to 
get to the interactive input. You also need to be root to do this.

> 
>> - Do the same steps as above with your opengl application.
> 
> I can´t see that because i have to kill it before the computer (telnet) 
> responds to any commands. At least i think i am killing it (i am 
> pressing the x button and then things seem to work again (if you are 
> using telnet)..

This is rather strange.. if you can click in the close button that means 
that X it's still alive there.. It's still not clear what is failing here..

> 
>> 
>> Before attempt to do the above get debug info from the DRM, doing from 
>> a X console as root:
>> After the computer has crashed send that kmsg.
> 
> Attached aswell...

There is no kernel oops there. Don't know if the last call there could 
have problems or not.

>> Take the time you need, as this can be a little boring.
> 
> It sure is, but it is worth it!
> 
> I also have another question, the mach64-0-0-4 branch is based on mesa 
> 4.0.2 right? Just wondering since the libGL is version 1.2 while the 
> version of libGL you get when compiling mesa 4.0.2 is 1.3.402. I just 
> thought that this might cause the problems, the libGL for mesa 3.3 (or 
> something) was called libGL.so.1.2. I just want to make sure that the 
> software configuration isn´t causing the problems...

If when you run 'glxinfo' you see there Mach64 somewhere in the beginning 
you should be fine. Also, you should be able to run the app as software 
rendering only too by making:

        LIBGL_ALWAYS_INDIRECT=1 glxgears
         
> 
> Peter
> 

You could try to start the GL app (or even the X afterwards) by a remote 
telnet connection. Just do

  gdb glxgears
  run
  continue              (it always breakspoints due to the SSE extensions 
check)

In case there is a segfault you should be able to do "bt", otherwise press 
Ctrl-C and then get the backtrace.


Another thing that needs to be checked, is that the endian is also 
accounted in the DDX, especially in the atidri.c file.


Regards,

José Fonseca



_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to