Comment # 69
on bug 105425
from iive@yahoo.com
I'm really out of ideas... Could you try using only the radeon kernel driver, just blacklist amdgpu one. See if the blender trace hangs and netconsole still doesn't give any warnings. See if you can completely disable iommu, when using radeon.ko. I've asked you at least 3 times to test "export mesa_glthread=false", but you never included it in your list of things you've tried. Same for `export RADEON_THREAD=false`. I haven't asked you, but add `MESA_DEBUG=flush` to the things to test. Now, if you have run out of things to test. You can try a prolonged experiment, that might not even bring usable result. If we had a case that hanged reliably, one thing to do is to locate the exact operation that causes the hang. So, you start `qapitrace` with the blender trace. You then do a binary search for the frame that causes hang. It's done by "Lookup State" at a frame number, it would replay the trace to that frame. You start with the full range, let's say [0 - 10000], so you pick the frame from the middle of that range, in this case frame#5000. If it hangs during replay, you use [0 - 5000] as interval, if it doesn't hang, then you use the other half [5000-10000] (because the cause of hang mush be there). Then you pick the middle of the new interval and repeat the experiment. (e.g. [0 - 2500]; [1250 - 2500]; [1250 - 1875]. Once you locate the exact frame that could cause the first hang, you can do the binary search, but this time on the draw operations inside that frame. It can help if you set: "qapitrace->Trace->Options->Only_show_the_following_events->Draw_events". Now, since crashing to you is kind of random, you might try to disable all threaded options (all options from above) and run same lookup a dozen of times. If it crashes even once, then it crashes. Also, be sure to write down the current range, as to not loose it at reboot. I also strongly encourage you to at least try some other distribution, something you can start from life-cd or something. Or build your own vanilla kernel.
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
