Comme=
nt # 33
on bug 10573=
3
from <=
span class=3D"fn">Allan
(In reply to Jan Jurzitza from comment #31)
> I have found a workaround (amd patched kernel no=
t required):
>=20
> cat /sys/class/drm/card0/device/pp_dpm_sclk
> # insert appropriate index here, I went for 1077Mhz
> echo 3 > /sys/class/drm/card0/device/pp_dpm_sclk
>=20
> Makes the GPU a bit slower (changes clock to 1077 Mhz on my card) for =
the
> session, but at least applications don't freeze the system anymore now=
(or
> at least this is delaying it so much that it works for multiple hours,=
but
> it didn't freeze for me yet)
>=20
> Though because of the slowdown I don't think this is a good solution
> long-term. Maybe a hint towards a solution though maybe? What I notice=
d in
> radeon-profile is that on auto it is capable of running at the boost
> frequency (1266 Mhz) and not limited to the base frequency the product=
page
> specifies (1120 Mhz) by default, so I changed it here and it basically=
fixed
> it.
>=20
> Fixes the issue on kernel 4.18.4
Even that I didn't mention, I tried it.
It worked for me for a while, and most part while I wasn't properly running=
3D
rendering, but OpenCL codes instead.
But it never worked as a workaround cause it just randomized the time to ha=
ppen
the errors.
And this is exactly why I didn't mention it before.
Indeed, I need to test it on kernel 4.18 yet.
###########################################################################=
####
In time : seems like that the warranty of my motherboard will take a long t=
ime
to finish.
I borrowed an old PC from my aunt and I hope that it will be enough to comp=
ile
the kernel and test the GPU. It is going to be fun to compile a kernel on a
1.6GHz dual core (1C/2T).