All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Turner <mattst88@gmail.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	Ben Widawsky <ben@bwidawsk.net>, Matt Turner <mattst88@gmail.com>
Subject: Re: [PATCH 02/13] drm/i915: Copy user requested buffers into the error state
Date: Fri, 14 Apr 2017 21:49:34 -0700	[thread overview]
Message-ID: <CAEdQ38EAKhRbGX0swFbcOWS9S6v8+Y2WKqWsfTv+0TQGPRdyMQ@mail.gmail.com> (raw)
In-Reply-To: <20170412214355.GO12532@nuc-i3427.alporthouse.com>

On Wed, Apr 12, 2017 at 2:43 PM, Chris Wilson <chris@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@bwidawsk.net>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Ben Widawsky <ben@bwidawsk.net>
>> Cc: Matt Turner <mattst88@gmail.com>
>> Acked-by: Ben Widawsky <ben@bwidawsk.net>
>> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@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!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-04-15  4:49 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 15:56 Another week, another eb bomb Chris Wilson
2017-03-29 15:56 ` [PATCH 01/13] drm/i915: Reinstate reservation_object zapping for batch_pool objects Chris Wilson
2017-03-29 15:56 ` [PATCH 02/13] drm/i915: Copy user requested buffers into the error state Chris Wilson
2017-04-02  0:48   ` Matt Turner
2017-04-02  8:51     ` Chris Wilson
2017-04-12 21:43   ` Chris Wilson
2017-04-15  4:49     ` Matt Turner [this message]
2017-04-15 11:42       ` Chris Wilson
2017-03-29 15:56 ` [PATCH 03/13] drm/i915: Amalgamate execbuffer parameter structures Chris Wilson
2017-03-29 15:56 ` [PATCH 04/13] drm/i915: Use vma->exec_entry as our double-entry placeholder Chris Wilson
2017-03-31  9:29   ` Joonas Lahtinen
2017-04-10 10:30     ` Chris Wilson
2017-03-29 15:56 ` [PATCH 05/13] drm/i915: Split vma exec_link/evict_link Chris Wilson
2017-03-29 15:56 ` [PATCH 06/13] drm/i915: Store a direct lookup from object handle to vma Chris Wilson
2017-03-31  9:56   ` Joonas Lahtinen
2017-03-29 15:56 ` [PATCH 07/13] drm/i915: Pass vma to relocate entry Chris Wilson
2017-03-29 15:56 ` [PATCH 08/13] drm/i915: Eliminate lots of iterations over the execobjects array Chris Wilson
2017-04-04 14:57   ` Joonas Lahtinen
2017-04-10 12:17     ` Chris Wilson
2017-04-11 20:45     ` [PATCH v4] " Chris Wilson
2017-03-29 15:56 ` [PATCH 09/13] drm/i915: First try the previous execbuffer location Chris Wilson
2017-03-29 15:56 ` [PATCH 10/13] drm/i915: Wait upon userptr get-user-pages within execbuffer Chris Wilson
2017-03-29 15:56 ` [PATCH 11/13] drm/i915: Allow execbuffer to use the first object as the batch Chris Wilson
2017-03-29 15:56 ` [PATCH 12/13] drm/i915: Async GPU relocation processing Chris Wilson
2017-04-03 13:54   ` Joonas Lahtinen
2017-03-29 15:56 ` [PATCH 13/13] drm/i915/scheduler: Support user-defined priorities Chris Wilson
2017-03-29 16:17 ` ✓ Fi.CI.BAT: success for series starting with [01/13] drm/i915: Reinstate reservation_object zapping for batch_pool objects Patchwork
2017-04-11 20:47 ` ✗ Fi.CI.BAT: failure for series starting with [01/13] drm/i915: Reinstate reservation_object zapping for batch_pool objects (rev2) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEdQ38EAKhRbGX0swFbcOWS9S6v8+Y2WKqWsfTv+0TQGPRdyMQ@mail.gmail.com \
    --to=mattst88@gmail.com \
    --cc=ben@bwidawsk.net \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.