From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 4/5] drm/i915: don't trylock in the gpu reset code Date: Mon, 25 Jun 2012 21:10:26 +0100 Message-ID: <1340655069_69543@CP5-2952> References: <1340548956-4097-1-git-send-email-daniel.vetter@ffwll.ch> <1340548956-4097-5-git-send-email-daniel.vetter@ffwll.ch> 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 DACD29E7D8 for ; Mon, 25 Jun 2012 13:11:13 -0700 (PDT) In-Reply-To: <1340548956-4097-5-git-send-email-daniel.vetter@ffwll.ch> 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: Intel Graphics Development Cc: Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org On Sun, 24 Jun 2012 16:42:35 +0200, Daniel Vetter wrote: > Simply failing to reset the gpu because someone else might still hold > the mutex isn't a great idea - I see reliable silent reset failures. > And gpu reset simply needs to be reliable and Just Work. GPU reset needs to just work, and if it can't then we need to avoid locking up the machine... Consider hitting an OOPS whlist holding the struct mutex and then getting a hang, we end up with a struct worker thread. Not as bad as it once was, but it can still make rebooting tricky at times. How about a compromise, while(!timeout) {if (trylock()) break; msleep(1); } ? -Chris -- Chris Wilson, Intel Open Source Technology Centre