Re: [PATCH] drm/i915/byt: Avoid tweaking evaluation thresholds

From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Len Brown <len.brown@intel.com>, Michal Feix <michal@feix.cz>,
	Jani Nikula <jani.nikula@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, fritsch@xbmc.org,
	Hans de Goede <hdegoede@redhat.com>,
	miku@iki.fi, Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
	"# v4 . 2+" <stable@vger.kernel.org>
Subject: Re: [PATCH] drm/i915/byt: Avoid tweaking evaluation thresholds
Date: Wed, 25 Jan 2017 15:09:04 +0200	[thread overview]
Message-ID: <87d1fb9thr.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20170125124227.GC30843@nuc-i3427.alporthouse.com>

Chris Wilson <chris@chris-wilson.co.uk> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx