--- Comment #27 from ---
Loosing recently written files is unfortunately way too common, despite all
filesystem using journaling.
It might help if you call `sync` after writing the file. 

If you have kernel with enabled magic-sysrq, after crash you could hold
"Alt+PrintScrn+" and then press (one by one) "s" to sync, "u" to umount and "b"
to reboot.
All info about it could be found in: 

Since now hangs happen in a minute after starting gameplay, does that mean that
the "workarounds" that you reported previously doesn't help anymore?

Few ideas to test.
1. Try disabling gallium threads. They are recent feature and it seems they've
been working a lot in your graphs.
`export mesa_glthread=false`
Check also /etc/drirc , ~/.drirc  etc...

2. I'm not quite sure what is the difference between num_shaders_created and
num_compilations, but at the crash there are 2 shaders created and 0 compiled.
This reminds me that you might want to turn off the shader cache. This might
introduce some stuttering during gameplay.

3. Your framerate is limited to 60fps. It's synced to your monitor vertical
refresh. Try 
`export vblank_mode=1` 
and see if you can control it from the game.
See what happens when you disable it. (Might make things much worse, much

4. Generally it is not good idea to test hangs with real game play. It is too
random. It would be ideal if you can record an apitrace that would reproduce
the hang reliably.
Obviously it might not be possible to do that recording on the system that
hangs. (The trace could be lost at reboot, or the commands that cause the hang
might not even be written).
If you have another machine or video card, that works reliably, try recording
gameplay of a single level. Then do the test replaying it. Would it play
entirely, would it hang, would it hang at the same place?

Can you trigger hang with `glxgears` ?

5. You might find something else to test here (e.g. disable DRI3?):

You are receiving this mail because:
You are the assignee for the bug.
dri-devel mailing list

Reply via email to