On Thu, Nov 26, 2015 at 09:36:14AM +0100, Daniel Vetter wrote: > On Wed, Nov 25, 2015 at 04:34:13PM +0000, Chris Wilson wrote: > > On Wed, Nov 25, 2015 at 04:29:01PM +0000, Chris Wilson wrote: > > > On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote: > > > > This testcase tries to validate -EIO behaviour by disabling gpu reset > > > > support in the kernel. Except that the wait subtest forgot to do that, > > > > and therefore gets a return value of 0 instead of the expected -EIO. > > > > > > > > > > Wrong. It was intentionally not using reset=false. > > > > To be more precise, the reason here is that we are not wedging the GPU > > but the expectation is that a wait upon a request that hangs reports the > > hang. Since the wait on GPU activity is explicit in the ioctl, the > > presumption is that the user actually cares about that activity and so > > should be given greater information about how it completes (timeout, GPU > > hung, or success). > > The only place we reprt hangs is in the reset_stats_ioctl. And > fundamentally wait_ioctl can't do (right now) what you want, since if the > reset recovery happens before userspace calls wait_ioctl then it will > happily return 0 for success. > > So if you want this then we need: > - a reason for userspace to want this > - reorg all our reset handling and move (or well copy) the reset stats to > every object I buy that if it resets before the wait_ioctl then it is invisible, which makes the information incomplete. I still think that as a caller of wait_ioctl, knowing that my wait was broken by a reset is valuable information. The drivers use some form of waiting to throttle themselves, therefore it is a convenient way of having the information that a reset has occurred and take action. This usecase also wouldn't miss a reset happening. You may disagree about wait_ioctl, but a wait_fence must definitely report EIO. (And this is as close to wait_fence as we currently have in the code and in use today.) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
