On Thu, Jun 18, 2015 at 12:18:39PM +0100, Tomas Elf wrote: > My point was more along the lines of bailing out if the reset > request fails and not return an error message but simply keep track > of the number of times we've attempted the reset request. By not > returning an error we would allow more subsequent hang detections to > happen (since the hang is still there), which would end up in the > same reset request in the future. If the reset request would fail > more times we would simply increment the counter and at one point we > would decide that we've had too many unsuccessful reset request > attempts and simply go ahead with the reset anyway and if the reset > would fail we would return an error at that point in time, which > would result in a terminally wedged state. But, yeah, I can see why > we shouldn't do this. Skipping to the middle! I understand the merit in trying the reset a few times before giving up, it would just need a bit of restructuring to try the reset before clearing gem state (trivial) and requeueing the hangcheck. I am just wary of feature creep before we get stuck into TDR, which promises to change how we think about resets entirely. I am trying not to block your work by doing "it would be nice if" tasks first! :) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
