All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3] drm/i915: Fix recursive calls to unmap
Date: Tue, 17 Jan 2012 12:15:37 +0100	[thread overview]
Message-ID: <20120117111537.GK4093@phenom.ffwll.local> (raw)
In-Reply-To: <20111103152339.46fe6ce8@bwidawsk.net>

On Thu, Nov 03, 2011 at 03:23:39PM -0700, Ben Widawsky wrote:
> On Thu, 3 Nov 2011 20:19:23 +0000
> Dave Airlie <airlied@gmail.com> wrote:
> 
> > >> >
> > >> > The solution here is to add a new flag to the call chain which gives the
> > >> > routines the information they need to possibly defer actions which may
> > >> > cause us to recurse. A macro has been defined to replace i915_gpu_idle
> > >> > which defaults to the old behavior.
> > >> >
> > >> > Kudos to Chris for tracking this one down.
> > >>
> > >> So this fixes the non-VTd case, the VT-d case still hits a recursion
> > >> here, for posterity its below.
> > 
> > Okay I take that back, I got my EL6 kernel rock stable with the
> > correct blend of backported bits.
> > 
> > So ignore that backtrace, however I did get another IOMMU hang on my
> > upstream kernel with gem_linear_blits,
> > 
> > so this should be fine to merge but I'm guessing we have more
> > debugging to do on the VT-d cases.
> > 
> > Dave.
> 
> Does it pass your original failing case?

Hi Ben,

Is v3 of this patch the right one to merge or do we still have some
outstanding issues on this? Also, have you looked at the recent ilk dmar
fallout, I think strict dmar iotlb flushing doesn't sit too well with our
gpus. My snb dies almost immediately with that (even when I do not enable
rc6 nor semaphores).

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

      reply	other threads:[~2012-01-17 11:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-31  3:16 [PATCH v3] drm/i915: Fix recursive calls to unmap Ben Widawsky
2011-10-31  7:45 ` Daniel Vetter
2011-11-02 19:29 ` Dave Airlie
2011-11-03  4:47   ` Ben Widawsky
2011-11-03 20:19     ` Dave Airlie
2011-11-03 22:23       ` Ben Widawsky
2012-01-17 11:15         ` Daniel Vetter [this message]

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=20120117111537.GK4093@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ben@bwidawsk.net \
    --cc=daniel.vetter@ffwll.ch \
    --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.