From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mika Kuoppala Subject: Re: [PATCH] drm/i915/byt: Avoid tweaking evaluation thresholds Date: Wed, 25 Jan 2017 15:09:04 +0200 Message-ID: <87d1fb9thr.fsf@gaia.fi.intel.com> References: <1485347468-7059-1-git-send-email-mika.kuoppala@intel.com> <20170125124227.GC30843@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 06B1C6E9D0 for ; Wed, 25 Jan 2017 13:10:18 +0000 (UTC) In-Reply-To: <20170125124227.GC30843@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: Len Brown , Michal Feix , Jani Nikula , Daniel Vetter , intel-gfx@lists.freedesktop.org, fritsch@xbmc.org, Hans de Goede , miku@iki.fi, Jarkko Nikula , Ezequiel Garcia , "# v4 . 2+" List-Id: intel-gfx@lists.freedesktop.org Q2hyaXMgV2lsc29uIDxjaHJpc0BjaHJpcy13aWxzb24uY28udWs+IHdyaXRlczoKCj4gT24gV2Vk LCBKYW4gMjUsIDIwMTcgYXQgMDI6MzE6MDhQTSArMDIwMCwgTWlrYSBLdW9wcGFsYSB3cm90ZToK Pj4gQ2VydGFpbiBCYXl0cmFpbHMsIG5hbWVseSB0aGUgNCBjcHUgY29yZSB2YXJpYW50cywgaGF2 ZSBiZWVuCj4+IHBsYXF1ZWQgYnkgc3B1cmlvdXMgc3lzdGVtIGhhbmdzLCBtb3N0bHkgb2NjdXJy aW5nIHdpdGggbGlnaHQgbG9hZHMuCj4+IAo+PiBNdWx0aXBsZSBiaXNlY3RzIGJ5IHZhcmlvdXMg cGVvcGxlIHBvaW50IHRvIGEgY29tbWl0IHdoaWNoIGNoYW5nZXMgdGhlCj4+IHJlY2xvY2tpbmcg c3RyYXRlZ3kgZm9yIEJheXRyYWlsIHRvIGZvbGxvdyBpdHMgYmlnZ2VyIGJyZXRoZW46Cj4+IGNv bW1pdCA4ZmI1NTE5N2U2NGQgKCJkcm0vaTkxNTogQWdyZXNzaXZlIGRvd25jbG9ja2luZyBvbiBC YXl0cmFpbCIpCj4+IAo+PiBUaGVyZSBpcyBhbHNvIGEgcmV2aWV3IGNvbW1lbnQgYXR0YWNoZWQg dG8gdGhpcyBjb21taXQgZnJvbSBEZWVwYWsgUwo+PiBvbiBhdm9pZGluZyBwdW5pdCBhY2Nlc3Mg b24gQ2hlcnJ5dmlldyBhbmQgdGh1cyBpdCBpcyBleGNsdWRlZCBvbgo+PiBjb21tb24gcmVjbG9j a2luZyBwYXRoLiBCeSB0YWtpbmcgdGhlIHNhbWUgYXBwcm9hY2ggYW5kIG9taXR0aW5nCj4+IHRo ZSBwdW5pdCBhY2Nlc3MgYnkgbm90IHR3ZWFraW5nIHRoZSB0aHJlc2hvbGRzIHdoZW4gdGhlIGhh cmR3YXJlCj4+IGhhcyBiZWVuIGFza2VkIHRvIG1vdmUgaW50byBkaWZmZXJlbnQgZnJlcXVlbmN5 LCBjb25zaWRlcmFibGUgZ2FpbnMKPj4gaW4gc3RhYmlsaXR5IGhhdmUgYmVlbiBvYnNlcnZlZC4K Pj4gCj4+IFdpdGggSjE5MDAgYm94LCBsaWdodCByZW5kZXIvdmlkZW8gbG9hZCB3b3VsZCBlbmQg dXAgaW4gc3lzdGVtIGhhbmcKPj4gaW4gdXN1YWxseSBsZXNzIHRoYW4gMTIgaG91cnMuIFdpdGgg dGhpcyBwYXRjaCBhcHBsaWVkLCB0aGUgY3VtdWxhdGl2ZQo+PiB1cHRpbWUgaGFzIG5vdyBiZWVu IDM0IGRheXMgd2l0aG91dCBpc3N1ZXMuIFRvIHByb3Zva2Ugc3lzdGVtIGhhbmcsCj4+IGxpZ2h0 IGxvYWRzIG9uIGJvdGggcmVuZGVyIGFuZCBic2QgZW5naW5lcyBpbiBwYXJhbGxlbCBoYXZlIGJl ZW4gdXNlZDoKPj4gZ2x4Z2VhcnMgPi9kZXYvbnVsbCAyPi9kZXYvbnVsbCAmCj4+IG1wdiAtLXZv PXZhYXBpIC0taHdkZWM9dmFhcGkgLS1sb29wPWluZiB2aWQubXA0Cj4+IAo+PiBTbyBmYXIsIGF1 dGhvciBoYXMgbm90IHdpdG5lc3NlZCBzeXN0ZW0gaGFuZyB3aXRoIGFib3ZlIGxvYWQKPj4gYW5k IHRoaXMgcGF0Y2ggYXBwbGllZC4gUmVwb3J0cyBmcm9tIHRoZSB0ZW5hY2lvdXMgcGVvcGxlIGF0 Cj4+IGtlcm5lbCBidWd6aWxsYSBhcmUgYWxzbyBwcm9taXNpbmcuCj4+IAo+PiBDb25zaWRlcmlu ZyB0aGF0IHRoZSBwdW5pdCBhY2Nlc3MgZnJlcXVlbmN5IHdpdGggdGhpcyBwYXRjaCBpcwo+PiBj b25zaWRlcmFibHkgbGVzcywgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0aGF0IHRoaXMgd2lsbCBw dXNoCj4+IHRoZSwgc3RpbGwgdW5rbm93biwgcm9vdCBjYXVzZSBwYXN0IHRoZSB0cmlnZ2VyaW5n IHBvaW50IG9uIG1vc3QgbG9hZHMuCj4+IEZ1cnRoZXIgd29yayBvbiBpbnZlc3RpZ2F0aW5nIHRo ZSBwdW5pdCBhY2Nlc3NlcyBvbiBieXQgaXMgd2VsY29tZWQuCj4KPiBQbGVhc2UgZmluZCB0aGUg dW5kZXJseWluZyBwcm9ibGVtIGFuZCBub3QgZGlzYWJsaW5nIHJwcyBmb3IgYWxsIHZsdgo+IGZv ciBhIEdUIHNwZWNpZmljIHByb2JsZW0uCgpUaGlzIGlzIG5vdCBkaXNhYmxpbmcgcnBzLgotTWlr YQoKPiAtQ2hyaXMKPgo+IC0tIAo+IENocmlzIFdpbHNvbiwgSW50ZWwgT3BlbiBTb3VyY2UgVGVj aG5vbG9neSBDZW50cmUKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KSW50ZWwtZ2Z4IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Au b3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwt Z2Z4Cg== 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