[Intel-gfx] [PATCH 02/13] drm/i915: Copy user requested buffers into the error state

Chris Wilson chris at chris-wilson.co.uk
Sat Apr 15 11:42:23 UTC 2017


On Fri, Apr 14, 2017 at 09:49:34PM -0700, Matt Turner wrote:
> On Wed, Apr 12, 2017 at 2:43 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Wed, Mar 29, 2017 at 04:56:24PM +0100, Chris Wilson wrote:
> >> Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
> >> use to indicate that it wants the contents of this buffer preserved in
> >> the error state (/sys/class/drm/cardN/error) following a GPU hang
> >> involving this batch.
> >>
> >> Use this at your discretion, the contents of the error state. although
> >> compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
> >> eternity (until the error state is destroyed).
> >>
> >> Based on an earlier patch by Ben Widawsky <ben at bwidawsk.net>
> >> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >> Cc: Ben Widawsky <ben at bwidawsk.net>
> >> Cc: Matt Turner <mattst88 at gmail.com>
> >> Acked-by: Ben Widawsky <ben at bwidawsk.net>
> >> Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> >
> > I believe Matt has userspace ready to make use of this flag and is happy
> > with the current ABI. Matt, are we ready to commit ourselves to this
> > interface?
> 
> Yes, from my end this interface works well.
> 
> I'm able to capture the instruction buffer, and recognize it by
> matching the "user" buffer's address with that specified by
> STATE_BASE_ADDRESS, and then disassemble the various programs
> contained within by inspecting the kernel start pointers.
> 
> Thanks for handling the kernel side of things!

Pushed. Will be part of v4.13. :|
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list