Comment # 56
on bug 105425
from MirceaKitsune
I've preformed the netconsole test today. After over an hour of learning how it works, I set it up and could confirm that system messages are properly received by netcat on the other computer. Unfortunately, as expected, no messages get sent at the time of the freeze: Even the netconsole kernel module dies immediately. The MESA parameters I mentioned don't seem to affect the freeze produced by the Blender trace either. For reference, my testing string was: export LIBGL_DEBUG=true LIBGL_NO_DRAWARRAYS=true LIBGL_DRI3_DISABLE=true MESA_DEBUG=true MESA_NO_ASM=true MESA_NO_MMX=true MESA_NO_3DNOW=true MESA_NO_SSE=true MESA_NO_ERROR=true MESA_GLSL_CACHE_DISABLE=true MESA_NO_MINMAX_CACHE=true RADEON_NO_TCL=true DRAW_NO_FSE=true DRAW_USE_LLVM=0 I retain my conviction that this is nothing hardware related. Mainly because the freeze doesn't seem to be affected by VRAM fill nor GPU stress, but by specific renderer features regardless of the complexity of the scene. I see no way in which for instance, a Blender scene with a load of high-poly objects won't ever trigger a hardware failure, but a Blender scene with a few low-poly objects can do so within seconds if some obscure conditions are just right. If anyone can suggest anything else, please do. This is the weirdest and most difficult test I've ever had to preform on a computer to debug a crash, mainly due to the way in which absolutely nothing seems to work. There's definitely a way to catch it... I just don't know what that is.
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
