Comment # 55
on bug 105425
from iive@yahoo.com
(In reply to MirceaKitsune from comment #54) > But there's a bizarre twist this time: When playing 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. > > This is very peculiar: The crash must be occurring beyond what apitrace 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 variables. >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=true` is set, then the other(MESA_NO_MMX=true ; MESA_NO_3DNOW=true ; MESA_NO_SSE=true) have no effect. And don't forget to test `export mesa_glthread=false` too. Also try `export RADEON_THREAD=false` 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 always 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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
