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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> > >> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >> Cc: Ben Widawsky <ben@xxxxxxxxxxxx> > >> Cc: Matt Turner <mattst88@xxxxxxxxx> > >> Acked-by: Ben Widawsky <ben@xxxxxxxxxxxx> > >> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
