From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com ([134.134.136.20]:1348 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751893AbdAYNKa (ORCPT ); Wed, 25 Jan 2017 08:10:30 -0500 From: Mika Kuoppala To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org, Ville =?utf-8?B?U3lyasOkbMOk?= , Len Brown , Daniel Vetter , Jani Nikula , fritsch@xbmc.org, miku@iki.fi, Ezequiel Garcia , Michal Feix , Hans de Goede , Deepak S , Jarkko Nikula , "# v4 . 2+" Subject: Re: [PATCH] drm/i915/byt: Avoid tweaking evaluation thresholds In-Reply-To: <20170125124227.GC30843@nuc-i3427.alporthouse.com> References: <1485347468-7059-1-git-send-email-mika.kuoppala@intel.com> <20170125124227.GC30843@nuc-i3427.alporthouse.com> Date: Wed, 25 Jan 2017 15:09:04 +0200 Message-ID: <87d1fb9thr.fsf@gaia.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: stable-owner@vger.kernel.org List-ID: Chris Wilson writes: > On Wed, Jan 25, 2017 at 02:31:08PM +0200, Mika Kuoppala wrote: >> Certain Baytrails, namely the 4 cpu core variants, have been >> plaqued by spurious system hangs, mostly occurring with light loads. >> >> Multiple bisects by various people point to a commit which changes the >> reclocking strategy for Baytrail to follow its bigger brethen: >> commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail") >> >> There is also a review comment attached to this commit from Deepak S >> on avoiding punit access on Cherryview and thus it is excluded on >> common reclocking path. By taking the same approach and omitting >> the punit access by not tweaking the thresholds when the hardware >> has been asked to move into different frequency, considerable gains >> in stability have been observed. >> >> With J1900 box, light render/video load would end up in system hang >> in usually less than 12 hours. With this patch applied, the cumulative >> uptime has now been 34 days without issues. To provoke system hang, >> light loads on both render and bsd engines in parallel have been used: >> glxgears >/dev/null 2>/dev/null & >> mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4 >> >> So far, author has not witnessed system hang with above load >> and this patch applied. Reports from the tenacious people at >> kernel bugzilla are also promising. >> >> Considering that the punit access frequency with this patch is >> considerably less, there is a possibility that this will push >> the, still unknown, root cause past the triggering point on most loads. >> Further work on investigating the punit accesses on byt is welcomed. > > Please find the underlying problem and not disabling rps for all vlv > for a GT specific problem. This is not disabling rps. -Mika > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre