From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 1/5] drm/i915: Suppress EIO during set-to-gtt Date: Wed, 18 Apr 2012 10:10:22 +0100 Message-ID: <1334740243_17732@CP5-2952> References: <1334393751-8921-1-git-send-email-chris@chris-wilson.co.uk> <20120418090303.GF5315@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from fireflyinternet.com (smtp.fireflyinternet.com [109.228.6.236]) by gabe.freedesktop.org (Postfix) with ESMTP id 7ACD7A0ADD for ; Wed, 18 Apr 2012 02:10:45 -0700 (PDT) In-Reply-To: <20120418090303.GF5315@phenom.ffwll.local> 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: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 18 Apr 2012 11:03:03 +0200, Daniel Vetter wrote: > 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. I disagree with this approach. I need the driver to robust its own failures so that we don't lose data. I know from experience that is currently not. Looking at the code paths required for CPU access and making them resilient as possible is a necessary evil, imho. -Chris -- Chris Wilson, Intel Open Source Technology Centre