Comme=
nt # 55
on bug 10542=
5
from iive@yahoo.com
(In reply to MirceaKitsune from comment #54)
> But there's a bizarre twist this time: When play=
ing back the trace generated
> by Blender, my system will freeze at various points during the replay!
> Sometimes it freezes early, sometimes it freezes late, at other times =
I can
> replay the whole trace without getting a freeze at all.
>=20
> This is very peculiar: The crash must be occurring beyond what apitrac=
e is
> even capturing, likely something deep in the kernel or renderer which =
is
> only triggered when the conditions are just right. What do you make of=
this?
Well, this makes hardware issue a lot more probable.
Still, it is good that you have a trace that can trigger crashes.
Having an apitrace issuing same OpenGL commands eliminates a lot of variabl=
es.=20
>>From now on, you shell be using only this trace for your tests.
But first, you should try and setup `netconsole`.
I haven't used it myself so I can't give you any hints.
Still the documentation looks detailed. AFAIR you have it as module.
After you have it working, you can resume your experiments with environment
variables. And keep an eye on the kernel messages when a crash happens.
Few hints. If `MESA_NO_ASM=3Dtrue` is set, then the other(MESA_NO_MMX=3Dtru=
e ;
MESA_NO_3DNOW=3Dtrue ; MESA_NO_SSE=3Dtrue) have no effect.
And don't forget to test `export mesa_glthread=3Dfalse` too.
Also try `export RADEON_THREAD=3Dfalse` with the above.
Threading and concurrency just increase the random variables.
Your hope is to find something that always works, or some error that is alw=
ays
present before crash.
You should also seriously consider testing the card on other OS or computer.
If that blender trace hangs on Windows, it definitely is not software issue.
Keep digging.