[Intel-gfx] -ERESTARTSYS on ioctl

Chris Wilson chris at chris-wilson.co.uk
Wed Jan 6 22:55:36 CET 2010


On Wed, 06 Jan 2010 19:10:12 +0000, Peter Clifton <pcjc2 at cam.ac.uk> wrote:
> I've got this in my dmesg output:
> 
> [ 3341.199958] [drm:i915_gem_execbuffer] *ERROR* i915_gem_do_execbuffer
> returns -512

No need for a DRM_ERROR() there, all potential user errors are warned
about inside i915_gem_do_execbuffer()

> Tracking it down, it seems -512 is -ERESTARTSYS
> 
> 
> Should that be handled as a somewhere? Most cases seem to special case
> it as "not an error".
> 
> I'm not sure how ERESTARTSYS is (or should be handled), but after using
> Google, I infer that it means something to do with the kernel
> auto-magically restarting an interrupted system call, but that if it
> cannot, it ends up converted to an EINTR returned to userspace.
> 
> In i915_gem_execbuffer(), i915_gem_do_execbuffer() returning ERESTARTSYS
> isn't caught explicitly, so the routine goes on to free exec_list and
> exec2_list. Does that cause any issue with a potential automatic restart
> of the original system call?

No, we have to free the locally allocated arrays before handing back
control to the higher layers.

> I'm using Ubuntu xorg-edgers drm, which is git HEAD, plus a revert of
> "intel: Repeat execbuffer after EINTR". Is reverting this a good idea?

No reverting that is not a good idea, since that patch exists to fix
precisely this issue. If the driver returns ERESTARTSYS that is translated
to EINTR for userspace, hence why we need to repeat the ioctl in libdrm.
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list