All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 6/9] drm/i915: driver based PASID handling
Date: Fri, 9 Oct 2015 09:52:41 +0200	[thread overview]
Message-ID: <20151009075230.GA26718@phenom.ffwll.local> (raw)
In-Reply-To: <20151009072837.GB18060@phenom.ffwll.local>

On Fri, Oct 09, 2015 at 09:28:37AM +0200, Daniel Vetter wrote:
> On Thu, Oct 08, 2015 at 11:46:08PM +0100, David Woodhouse wrote:
> > On Thu, 2015-10-08 at 12:29 +0100, Tomas Elf wrote:
> > > 
> > > Could someone clarify what this means from the TDR point of view, 
> > > please? When you say "context blew up" I'm guessing that you mean that 
> > > come context caused the fault handler to get involved somehow?
> > > 
> > > Does this imply that the offending context will hang and the driver will 
> > > have to detect this hang? If so, then yes - if we have the per-engine 
> > > hang recovery mode as part of the upcoming TDR work in place then we 
> > > could handle it by stepping over the offending batch buffer and moving 
> > > on with a minimum of side-effects on the rest of the driver/GPU.
> > 
> > I don't think the context does hang.
> > 
> > I've made the page-request code artificially fail and report that it
> > was an invalid page fault. The gem_svm_fault test seems to complete
> > (albeit complaining that the test failed). Whereas if I just don't
> > service the page-request at all, *then* the GPU hang is detected.
> > 
> > I haven't actually looked at precisely what *is* happening.
> 
> Hm if this still works the same way as on older platforms then pagefaults
> just read all 0 and writes go nowhere from the gpu. That generally also
> explains ever-increasing numbers of the CS execution pointer since it's
> busy churning through 48b worth of address space filled with MI_NOP. I'd
> have hoped our hw would do better than that with svm ...
> 
> If there's really no way to make it hang when we complete the fault then I
> guess we'll have to hang it by not completing. Otherwise we'll have to
> roll our own fault detection code right from the start.

s/detection/handling/ I meant ofc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-10-09  7:49 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04 16:58 [RFC] Page table sharing and bufferless execbuf Jesse Barnes
2015-09-04 16:58 ` [PATCH 1/9] mm: move mmu_find_ops to mmu_notifier.c Jesse Barnes
2015-09-04 16:58 ` [PATCH 2/9] signal: export force_sig_info Jesse Barnes
2015-09-04 16:58 ` [PATCH 3/9] android/sync: add sync_fence_create_dma Jesse Barnes
2015-09-04 16:58 ` [PATCH 4/9] android/sync: hack: enable fence signaling in Android Native Sync implementation Jesse Barnes
2015-09-04 16:58 ` [PATCH 5/9] drm/i915: add create_context2 ioctl Jesse Barnes
2015-09-04 16:59 ` [PATCH 6/9] drm/i915: driver based PASID handling Jesse Barnes
2015-10-07 13:00   ` David Woodhouse
2015-10-07 15:16     ` Jesse Barnes
2015-10-07 16:14       ` Daniel Vetter
2015-10-07 16:28         ` Jesse Barnes
2015-10-07 17:17           ` David Woodhouse
2015-10-07 17:26             ` Jesse Barnes
2015-10-08  8:12               ` Daniel Vetter
2015-10-08 10:28         ` Tomas Elf
2015-10-08 11:29         ` Tomas Elf
2015-10-08 22:46           ` David Woodhouse
2015-10-09  7:28             ` Daniel Vetter
2015-10-09  7:52               ` Daniel Vetter [this message]
2015-10-09  7:56               ` David Woodhouse
2015-10-09  8:47                 ` Daniel Vetter
2015-10-09  9:07                   ` David Woodhouse
2015-10-09 16:20                     ` Jesse Barnes
2015-10-08 15:57   ` Chris Wilson
2015-10-09  7:24     ` David Woodhouse
2015-09-04 16:59 ` [PATCH 7/9] drm/i915: add fences to the request struct Jesse Barnes
2015-10-09 13:29   ` David Woodhouse
2015-10-09 16:11     ` Jesse Barnes
2015-09-04 16:59 ` [PATCH 8/9] drm/i915: Android sync points for i915 v4 (obsolete) Jesse Barnes
2015-09-04 16:59 ` [PATCH 9/9] drm/i915: add bufferless execbuf ioctl Jesse Barnes
2015-09-04 17:37   ` Chris Wilson
2015-09-04 19:09     ` Jesse Barnes
2015-10-08 10:34   ` David Woodhouse
2015-09-04 17:23 ` [RFC] Page table sharing and bufferless execbuf Chris Wilson
2015-09-04 19:08   ` Jesse Barnes
2015-09-26 14:55 ` David Woodhouse

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=20151009075230.GA26718@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dwmw2@infradead.org \
    --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.