From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing Date: Wed, 20 Jan 2016 15:29:27 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0264507631==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 9C8906E973 for ; Wed, 20 Jan 2016 07:29:28 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0264507631== Content-Type: multipart/alternative; boundary="14533037680.D2A3bF.8480"; charset="UTF-8" --14533037680.D2A3bF.8480 Date: Wed, 20 Jan 2016 15:29:28 +0000 MIME-Version: 1.0 Content-Type: text/plain https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #63 from Julian --- Well, "fixed" :p I've used the patched module for 5-6 hours without issues now. So this version checks out. Next is with sclk_dpm_key_disabled = 0 and mclk_dpm_key_disabled = 0; My guess is that this'll make the freeze happen again. I've dug through the sources in an attempt to understand what's going on. My hypothesis is that the lockup happens under rare circumstances when the driver switches from one performance_level to another. Forcing the highest or lowest perf level is fine, but 'auto' switches perf levels often enough that the bug will happen relatively soon. At first I thought it was an issue with the writeback feature that caches certain register values because it also caches an rptr value that is used in the driver's gpu_lockup_check and is, to my knowledge, never actually written to. Buuut using radeon.no_wb=1 doesn't help. So if I've found a bug it is not the culprit of the lockups. -- You are receiving this mail because: You are the assignee for the bug. --14533037680.D2A3bF.8480 Date: Wed, 20 Jan 2016 15:29:28 +0000 MIME-Version: 1.0 Content-Type: text/html

Comment # 63 on bug 91880 from 
Well, "fixed" :p

I've used the patched module for 5-6 hours without issues now. So this version
checks out.

Next is with sclk_dpm_key_disabled = 0 and mclk_dpm_key_disabled = 0;

My guess is that this'll make the freeze happen again. I've dug through the
sources in an attempt to understand what's going on. My hypothesis is that the
lockup happens under rare circumstances when the driver switches from one
performance_level to another. Forcing the highest or lowest perf level is fine,
but 'auto' switches perf levels often enough that the bug will happen
relatively soon.

At first I thought it was an issue with the writeback feature that caches
certain register values because it also caches an rptr value that is used in
the driver's gpu_lockup_check and is, to my knowledge, never actually written
to.

Buuut using radeon.no_wb=1 doesn't help. So if I've found a bug it is not the
culprit of the lockups.

You are receiving this mail because:
  • You are the assignee for the bug.
--14533037680.D2A3bF.8480-- --===============0264507631== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0264507631==--