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! _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
