<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Radeon R9 270X GPU lockup on power profile change"
href="https://bugs.freedesktop.org/show_bug.cgi?id=77394#c16">Comment # 16</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Radeon R9 270X GPU lockup on power profile change"
href="https://bugs.freedesktop.org/show_bug.cgi?id=77394">bug 77394</a>
from <span class="vcard"><a class="email" href="mailto:nine@detonation.org" title="nine@detonation.org">nine@detonation.org</a>
</span></b>
<pre>Today I finally made decent progress on this issue. I can confirm that the GPU
lockups are not the X server's fault, since they appear also when using weston
and indeed, when running the eglkms Mesa demo on the pure framebuffer.
Trying to find the exact OpenGL call that causes the lockup, I discovered, that
when I change the power profile before starting any GL program (Mesa demo or
display server), it continues to work until the next reboot. So all that was
needed was a
echo low > /sys/class/drm/card0/device/power_profile
executed before starting the X server and I could change power profile at
runtime.
I then turned on dpm again and indeed:
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level
called by an ExecStartPre script from the display-server service file fixes the
issue completely for me and I have now a fully working dpm :)
So it seems like the first change of performance level/profile initializes
something that must be initialized before the first GL call or CRTC change for
power management to be stable. Any idea what this something might be?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>