From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 110674] Crashes / Resets From AMDGPU / Radeon VII Date: Sun, 11 Aug 2019 17:00:25 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2002538548==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id C56A76E393 for ; Sun, 11 Aug 2019 17:00:25 +0000 (UTC) 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 --===============2002538548== Content-Type: multipart/alternative; boundary="15655428253.816DA6EA.15976" Content-Transfer-Encoding: 7bit --15655428253.816DA6EA.15976 Date: Sun, 11 Aug 2019 17:00:25 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D110674 --- Comment #71 from Sylvain BERTRAND --- On Sun, Aug 11, 2019 at 01:15:48AM +0000, bugzilla-daemon@freedesktop.org wrote: > I think the clock dysregulation and excessive voltage/wattage are symptom= s of Is there a way to configure the smu block to keep the memory clock to its m= ax with the appropriate power/voltage? If the smu block do configure some of t= he vram arbiter block priority, could we tell it to keep the dc[en]x to max priority and ignore display vram watermarks? (due to the realtime requireme= nt of monitor data transmission, I still don't understand the existence of watermarks in the first place, I would need data which proves me wrong). On my AMD TAHITI XT, the memory clock seems to be locked to the max (only 1 full hd 144Hz monitor). I recall dce6 has fancy inner-blocks configuration:= I simplified it in my custom driver (something about availability of display clocks and memory bandwidth. Maybe the smu while clock/power managing breaks due this dc[en]x "fancy" inner-blocks configuration.=20 Additionnally, never heard of 2 displays which would be driven by a common display block and being in sync. Is the sync dependant on the monitors and = not the display block?? What I am missing ? The nasty displayport mst thingy? I would always set this to false. --=20 You are receiving this mail because: You are the assignee for the bug.= --15655428253.816DA6EA.15976 Date: Sun, 11 Aug 2019 17:00:25 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comme= nt # 71 on bug 11067= 4 from Sylvain BERTRAND
On Sun, Aug 11, 2019 at 01:15:48AM +0000, bugzilla-daemon@freedesktop.org
wrote:
> I think the clock dysregulation and excessive vo=
ltage/wattage are symptoms of

Is there a way to configure the smu block to keep the memory clock to its m=
ax
with the appropriate power/voltage? If the smu block do configure some of t=
he
vram arbiter block priority, could we tell it to keep the dc[en]x to max
priority and ignore display vram watermarks? (due to the realtime requireme=
nt
of monitor data transmission, I still don't understand the existence of
watermarks in the first place, I would need data which proves me wrong).

On my AMD TAHITI XT, the memory clock seems to be locked to the max (only 1
full hd 144Hz monitor). I recall dce6 has fancy inner-blocks configuration:=
 I
simplified it in my custom driver (something about availability of display
clocks and memory bandwidth. Maybe the smu while clock/power managing breaks
due this dc[en]x "fancy" inner-blocks configuration.=20

Additionnally, never heard of 2 displays which would be driven by a common
display block and being in sync. Is the sync dependant on the monitors and =
not
the display block??  What I am missing ? The nasty displayport mst thingy?
I would always set this to false.


You are receiving this mail because:
  • You are the assignee for the bug.
= --15655428253.816DA6EA.15976-- --===============2002538548== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============2002538548==--