From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 77394] Radeon R9 270X GPU lockup on power profile change
Date: Sat, 23 May 2015 13:41:27 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1095991491=="
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id DD2076E0C0
for ; Sat, 23 May 2015 06:41:27 -0700 (PDT)
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
--===============1095991491==
Content-Type: multipart/alternative; boundary="1432388487.baC6B40.23328"; charset="UTF-8"
--1432388487.baC6B40.23328
Date: Sat, 23 May 2015 13:41:27 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #16 from nine@detonation.org ---
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?
--
You are receiving this mail because:
You are the assignee for the bug.
--1432388487.baC6B40.23328
Date: Sat, 23 May 2015 13:41:27 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Comment # 16
on bug 77394
from nine@detonation.org
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?
You are receiving this mail because:
- You are the assignee for the bug.
--1432388487.baC6B40.23328--
--===============1095991491==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0
cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK
--===============1095991491==--