From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH] drm/i915: Check hangcheck is functioning before indefinite waits Date: Thu, 3 Jul 2014 09:00:45 -0700 Message-ID: <20140703090045.3f2cad4f@jbarnes-desktop> References: <1404371341-16967-1-git-send-email-chris@chris-wilson.co.uk> <20140703084420.0d8b8169@jbarnes-desktop> <20140703155111.GA23812@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by gabe.freedesktop.org (Postfix) with ESMTP id 5A42E6E722 for ; Thu, 3 Jul 2014 09:00:00 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id v10so434506pde.12 for ; Thu, 03 Jul 2014 09:00:00 -0700 (PDT) In-Reply-To: <20140703155111.GA23812@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Thu, 3 Jul 2014 16:51:11 +0100 Chris Wilson wrote: > On Thu, Jul 03, 2014 at 08:44:20AM -0700, Jesse Barnes wrote: > > On Thu, 3 Jul 2014 08:09:01 +0100 > > Chris Wilson wrote: > > > > > Since we rely on hangcheck to wait up and kick us out of an indefinite > > > wait should the GPU ever stop functioning, it appears sensible that we > > > should check that hangcheck is indeed active before starting that wait. > > > This just prevents a driver error in the processing of hangcheck from > > > appearing to hang the machine. > > > Are there any bugs associated with this? > > No open bugs. They have cropped up during dev though, and I think I am > not alone. I believe that both Ben and I have tried to convince Daniel > the merits of having this security blanket. > > > i915_rearm_hangcheck() or something might more accurately describe > > what's going on here. > > How about i915_ensure_hangcheck()? (I agree that rearm is better than > check.) > > > I suppose both of these paths are protected by the struct_mutex? If > > not, might we race and mod_timer() this twice from two threads in > > succession? I guess that's harmless... > > Concurrently arming a timer within a jiffie or two isn't going to make > too much difference, or even pushing an almost firing timer off by > another hangcheck interval. Conversely, since we already have read the > hangcheck counter, if the hangcheck does fire before we schedule(), that > will immediately wake us up and we will spot the hang. Sounds good. ensure_hangcheck() or update_hangcheck() are fine with me too. Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center