From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/5] drm/i915: Suppress EIO during set-to-gtt Date: Wed, 18 Apr 2012 11:03:03 +0200 Message-ID: <20120418090303.GF5315@phenom.ffwll.local> References: <1334393751-8921-1-git-send-email-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ey0-f177.google.com (mail-ey0-f177.google.com [209.85.215.177]) by gabe.freedesktop.org (Postfix) with ESMTP id 5C278A0A80 for ; Wed, 18 Apr 2012 02:02:06 -0700 (PDT) Received: by eaak13 with SMTP id k13so1827446eaa.36 for ; Wed, 18 Apr 2012 02:02:05 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1334393751-8921-1-git-send-email-chris@chris-wilson.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Sat, Apr 14, 2012 at 09:55:47AM +0100, Chris Wilson wrote: > If we fail to flush the rendering to an object already bound to the GTT > because the hardware is edge, all is good! > > Signed-off-by: Chris Wilson As already quickly discussed on irc, I'm not too happy about -EIO special casing in set_to_gtt_domain, set_to_cpu_domain and flush_fence. Imo, assuming that our hangcheck and wedging code works correctly, we should bail out of this, the reset code should reset all the gem tracking state and as long as we dont emit any new requests on the gpu, we should never need to wait for one and get a -EIO in return. Reconsidering the -EIO special case in unbind, I'm also not sure any more that this one's right. In normal operations we should never try to unbind an active object, which leaves us with the ilk vt-d workaround. That one should eat the -EIO itself, imo. Now given how well-tested that code is, I expect bugs. But imo the right course of action is to make that code testable first before we sprinkle -EIO handling all over the place. I've planned to resurrect my gpu hangman this week, and I'm thinking of ways to extend that to test our -EIO/gpu wedging code. Cheers, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48