Quoting Mika Kuoppala (2019-02-08 15:07:55) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > Quoting Mika Kuoppala (2019-02-08 09:46:01) > >> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > >> > >> > On wedging, we mark all executing requests as complete and all pending > >> > requests completed as soon as they are ready. Before unwedging though we > >> > wish to flush those pending requests prior to restoring default > >> > execution, and so we must wait. Do so interruptibly as we do not provide > >> > >> uninterruptibly? > >> > >> > the EINTR gracefully back to userspace in this case but persistent in > >> > >> be persistent? > >> > >> We lost the gracefullness due to not having the interruptible > >> mutex wait on reset path anymore? > > > > No. We never had graceful handling, as we could never propagate the > > EINTR from unwedge back to userspace so it became EIO instead. > > Now I managed to entertain atleast myself. > I try to find a deeper meaning so hard on this... > > and there it is, in plain sight: the return code > is not used. I really did read it before > but obviously no rampup in powerstate was involved. Exactly. A task for the future would be to use killable here, let the user die and leave the machine wedged. But that requires a bit more effort :) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
