From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH 3/5] drm/i915: don't return a spurious -EIO
	from intel_ring_begin
Date: Tue, 26 Jun 2012 10:30:40 +0100
Message-ID: <1340703083_75138@CP5-2952>
References: <1340548956-4097-1-git-send-email-daniel.vetter@ffwll.ch>
	<1340548956-4097-4-git-send-email-daniel.vetter@ffwll.ch>
	<1340656383_69674@CP5-2952>
	<20120625204903.GG4708@phenom.ffwll.local>
	<1340658438_69856@CP5-2952>
	<CAKMK7uEh7HKwWWmq+psV5Pjt3gXa+9-MwV539GAgz47shkT1gw@mail.gmail.com>
	<1340664792_70515@CP5-2952>
	<CAKMK7uGAwtkc55OjYvE5vhEtpGjfNwaZkjDRJ1sQ-WxjYADPng@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from fireflyinternet.com (smtp.fireflyinternet.com [109.228.6.236])
	by gabe.freedesktop.org (Postfix) with ESMTP id C225A9F509
	for <intel-gfx@lists.freedesktop.org>;
	Tue, 26 Jun 2012 02:31:25 -0700 (PDT)
In-Reply-To: <CAKMK7uGAwtkc55OjYvE5vhEtpGjfNwaZkjDRJ1sQ-WxjYADPng@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Tue, 26 Jun 2012 01:05:24 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> it would
> inevitably die on the next gtt pagefault. But I guess we can etch out
> a bit more survivability in corner cases.

Yeah, we need to do something about that pagefault-of-doom after EIO,
regardless. :(

I believe to do so we need a lot of the buffer management to be
resilient to EIO. But for proposed change to
i915_mutex_lock_interruptible(), I suggest we do something like
 int i915_mutex_lock_wedged()
 {
   ret = i915_mutex_lock_interruptible(dev);
   if (ret) {
     if (ret == -EIO) {
       if (mutex_trylock(&dev->struct_mutex))
         ret = 0;
       else
         ret = -EAGAIN;
     }       
   }
   return ret;
 }
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre