Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • A amd
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,474
    • Issues 1,474
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • drm
  • amd
  • Issues
  • #520
Closed
Open
Issue created Aug 24, 2014 by Bugzilla Migration User@bugzilla-migration

A problem related to Radeon DPM causes a corrupted console and black X display.

Submitted by Colin Carney

Assigned to Default DRI bug account

Link to original bug (#83023)

Description

Created attachment 105205
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

Attachment 105205, "The contents of dmesg":
dmesg.txt

Assignee
Assign to
Time tracking