Bug 83023 - A problem related to Radeon DPM causes a corrupted console and black X display.
Summary: A problem related to Radeon DPM causes a corrupted console and black X display.
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-24 21:47 UTC by Colin Carney
Modified: 2019-11-19 08:55 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
The contents of dmesg (71.52 KB, text/plain)
2014-08-24 21:47 UTC, Colin Carney
no flags Details
attachment-16801-0.html (3.09 KB, text/html)
2014-08-26 03:55 UTC, Colin Carney
no flags Details
attachment-16801-1.dat (1 bytes, multipart/alternative)
2014-08-26 03:55 UTC, Colin Carney
no flags Details
dmesg_radeon.dpm=1.txt (75.85 KB, text/plain)
2014-08-26 03:55 UTC, Colin Carney
no flags Details

Description Colin Carney 2014-08-24 21:47:06 UTC
Created attachment 105205 [details]
The contents of dmesg

Hello everyone,

I have a significant problem with my display related to the Dynamic Power Management of my radeonsi display driver.

I am running Arch Linux on my notebook computer, an HP EliteBook, model No. C7A70UT.  It has an AMD FirePro M4000 video card, which is very similar to a Radeon HD 7750M, both part of the Southern Islands series.  My video driver is Arch's current 'xf86-video-ati 1:7.4.0-3', which I suspect is a compiled and renamed version of Xorg's Radeon 7.4.

When I reinstalled Linux on my computer last fall, I set it up to boot to a console, and I may then start Xfce 4 from the command line.

The trouble is that as the computer boots, it at some point adjusts and clears the display.  After that time, the console display is somewhat obfuscated by grainy vertical lines of red, yellow, and green pixels.  The last message I can read before the display is adjusted is 'Reached Target Sound Card' and the first message in the corrupted display is 'Started trigger flashing of journal to persistent storage...'  (the dots '...' are part of the message).  There may be some messages that I am missing since I cannot pause the boot sequence - my notebook does not include a separate scroll lock key, and cntrl+s doesn't work very well.

More seriously, if I start X-windows the screen becomes completely black, and it remains black if I try to switch to another tty.  I don't know if the computer is otherwise running normally, or if the operating system realizes something is wrong.

Fortunately, I can partially work around the problem by forcing the video driver to use the 'high' setting, e.g. by using the command
# echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
After running that command, any areas of the screen which are re-drawn (e.g. newly typed characters, or the whole screen after switching to another tty) are drawn correctly and X will run normally.  However, my battery life is reduced from 3 hours to between 1 and 2 hours.
  
To the best of my understanding, my driver uses the setting in the file /sys/class/drm/card0/device/power_dpm_state to determine its operating state, and this is set to 'balanced' by default.  Changing the contents of that file to 'battery' or 'performance' does not resolve my bug.  Nor does setting /sys/class/drm/card0/device/power_dpm_force_performance_level to anything other than 'high' (i.e. 'low' or 'auto').

I first noticed this problem when I upgraded to the Arch 3.13.4-1 kernel (I think that was the first one which enabled DPM by default), and it still persists on my current kernel, Arch 3.16.1-1.  Prior to that time, I only set the dpm performance level to 'high' prior to playing 3-D games, and I never had any problems.

Please let me know if there is any other information I can provide to assist with the debugging process (perhaps output from lspci or a screenshot), or if I should send my bug report to someone else.

Thanks in Advance,


Colin Carney
Comment 1 Michel Dänzer 2014-08-25 01:41:53 UTC
Can you attach another dmesg from booting with radeon.dpm=1? That should give some more DPM related information.
Comment 2 Colin Carney 2014-08-26 03:55:10 UTC
Created attachment 105258 [details]
attachment-16801-0.html

I have booted with radeon.dpm=1, and I have attached a new dmesg file.


On Sun, Aug 24, 2014 at 8:41 PM, <bugzilla-daemon@freedesktop.org> wrote:

>  Michel Dänzer <michel@daenzer.net> changed bug 83023
> <https://bugs.freedesktop.org/show_bug.cgi?id=83023>
>  What Removed Added  Assignee xorg-driver-ati@lists.x.org
> dri-devel@lists.freedesktop.org  QA Contact xorg-team@lists.x.org
> Product xorg DRI  Version 7.4 (2008.09) unspecified  Component Driver/Radeon
> DRM/Radeon
>
>  *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=83023#c1> on
> bug 83023 <https://bugs.freedesktop.org/show_bug.cgi?id=83023> from Michel
> Dänzer <michel@daenzer.net> *
>
> Can you attach another dmesg from booting with radeon.dpm=1? That should give
> some more DPM related information.
>
>  ------------------------------
> You are receiving this mail because:
>
>    - You reported the bug.
>
>
Comment 3 Colin Carney 2014-08-26 03:55:10 UTC
Created attachment 105259 [details]
attachment-16801-1.dat
Comment 4 Colin Carney 2014-08-26 03:55:10 UTC
Created attachment 105260 [details]
dmesg_radeon.dpm=1.txt
Comment 5 Pablo Estigarribia 2017-08-27 13:11:42 UTC
I had to disable dpm on amdgpu too due to very similar bug on rx550 https://bugs.freedesktop.org/show_bug.cgi?id=101976
Comment 6 Alex Deucher 2017-08-28 16:09:16 UTC
(In reply to Pablo Estigarribia from comment #5)
> I had to disable dpm on amdgpu too due to very similar bug on rx550
> https://bugs.freedesktop.org/show_bug.cgi?id=101976

Different hardware and different drivers.  Not related even though the symptoms may be similar.
Comment 7 Martin Peres 2019-11-19 08:55:02 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/520.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.