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==--