From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B5B4C2D0DB for ; Tue, 28 Jan 2020 12:51:40 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 45A5424681 for ; Tue, 28 Jan 2020 12:51:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 45A5424681 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EB10B6EE29; Tue, 28 Jan 2020 12:51:39 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id ED6B66EE29 for ; Tue, 28 Jan 2020 12:51:38 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2020 04:51:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,373,1574150400"; d="scan'208";a="246708490" Received: from gaia.fi.intel.com ([10.237.72.192]) by orsmga002.jf.intel.com with ESMTP; 28 Jan 2020 04:51:37 -0800 Received: by gaia.fi.intel.com (Postfix, from userid 1000) id 6988D5C1E0F; Tue, 28 Jan 2020 14:50:50 +0200 (EET) From: Mika Kuoppala To: Chris Wilson , intel-gfx@lists.freedesktop.org In-Reply-To: <158021560766.2129.15846697702640801094@skylake-alporthouse-com> References: <20200127231540.3302516-1-chris@chris-wilson.co.uk> <20200127231540.3302516-6-chris@chris-wilson.co.uk> <877e1bn4il.fsf@gaia.fi.intel.com> <158021560766.2129.15846697702640801094@skylake-alporthouse-com> Date: Tue, 28 Jan 2020 14:50:50 +0200 Message-ID: <87y2trlp79.fsf@gaia.fi.intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH 6/6] drm/i915/gt: Lift set-wedged engine dumping out of user paths X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tomi Sarvela Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Chris Wilson writes: > Quoting Mika Kuoppala (2020-01-28 12:34:42) >> Chris Wilson writes: >> >> > The user (e.g. gem_eio) can manipulate the driver into wedging itself, >> > allowing the user to trigger voluminous logging of inconsequential >> > details. If we lift the dump to direct calls to intel_gt_set_wedged(), >> > out of the intel_reset failure handling, we keep the detail logging for >> > what we expect are true HW or test failures without being tricked. >> > >> > Reported-by: Tomi Sarvela >> > Signed-off-by: Chris Wilson >> > Cc: Mika Kuoppala >> > Cc: Tomi Sarvela >> > --- >> > drivers/gpu/drm/i915/gt/intel_reset.c | 30 +++++++++++++++++++-------- >> > 1 file changed, 21 insertions(+), 9 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c >> > index beee0cf89bce..423a02506b2d 100644 >> > --- a/drivers/gpu/drm/i915/gt/intel_reset.c >> > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c >> > @@ -800,13 +800,6 @@ static void __intel_gt_set_wedged(struct intel_gt *gt) >> > if (test_bit(I915_WEDGED, >->reset.flags)) >> > return; >> > >> > - if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(gt)) { >> > - struct drm_printer p = drm_debug_printer(__func__); >> > - >> > - for_each_engine(engine, gt, id) >> > - intel_engine_dump(engine, &p, "%s\n", engine->name); >> > - } >> > - >> > GT_TRACE(gt, "start\n"); >> > >> > /* >> > @@ -845,10 +838,29 @@ void intel_gt_set_wedged(struct intel_gt *gt) >> > { >> > intel_wakeref_t wakeref; >> > >> > + if (test_bit(I915_WEDGED, >->reset.flags)) >> > + return; >> > + >> > + wakeref = intel_runtime_pm_get(gt->uncore->rpm); >> > mutex_lock(>->reset.mutex); >> > - with_intel_runtime_pm(gt->uncore->rpm, wakeref) >> > - __intel_gt_set_wedged(gt); >> > + >> > + if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(gt)) { >> >> As you inspect each engine separately the precursory idle check >> seems superfluous. > > Picky. We may throw some other debug in between :) Not picky. Just my tinfoil hat too tight. Reviewed-by: Mika Kuoppala > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx