Bug 76130

BTW, my kernel is a stock Archlinux kernel 3.13.6.

Does this work better with a 3.14 kernel?

(In reply to comment #2)
> Does this work better with a 3.14 kernel?

I've just built 3.14 RC6 and it's all the the same with it.

Created attachment 100961 [details]
dmesg (Radeon HD 4550, 3.15.0)

I have the same problem with Radeon HD 4550 using kernel 3.14.5 or 3.15.0 or vanilla 3.15-rc1.
I have also noticed that `[drm:rv730_stop_dpm] *ERROR* Could not force DPM to low` appears only after some gaming/etc.

I'm also affected by this bug and I can confirm the performance hit after resuming the system from suspend.

Radeon HD 4330 + kernel 3.15.2

[ 4772.472528] [drm:rv730_stop_dpm] *ERROR* Could not force DPM to low
[ 4772.954683] [drm] PCIE GART of 1024M enabled (table at 0x000000000025D000).
[ 4773.002123] [drm] ring test on 0 succeeded in 1 usecs
[ 4773.002180] [drm] ring test on 3 succeeded in 1 usecs
[ 4773.187038] [drm] ring test on 5 succeeded in 1 usecs
[ 4773.187042] [drm] UVD initialized successfully.
[ 4773.187067] [drm] ib test on ring 0 succeeded in 0 usecs
[ 4773.187089] [drm] ib test on ring 3 succeeded in 1 usecs
[ 4773.337007] [drm] ib test on ring 5 succeeded
[ 4773.507776] [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed

Created attachment 108972 [details] [review]
possible fix

Does this patch help?

The patch does not seem to fix the problem here, still seeing the error messages in my log.
Can anyone else please test it?

Hi,

I also experience this problem with my laptop at resume from sleep. 

About log messages, there does not seem to be a message when entering sleep. When resuming from sleep, I can briefly see this message printed on the screen:

kernel: [drm:rv730_stop_dpm [radeon]] *ERROR* Could not force DPM to low

However at boot time, I see this in the log:

kernel: [drm] initializing kernel modesetting (RV710 0x1002:0x9553 0x1179:0xFF00).

I see a switch from rv710 to rv730, is this normal?
Previously, Thaddäus Tintenfisch reported a switch from rv730 to rv770...

If useful, the lspci command says:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series]

The patch proposed just before seems to be explicitely related to rv770, which does not seem to be my case.

I forgot to mention the OS I'm using:

ArchLinux x86-64
Linux 4.0 from testing repo (also happens with the kernel from core repo)
mesa 10.5.4 from stock core repo
xf86-video-ati 1:7.5 from stock core repo

No patch, no personal kernel boot options, basically zero config.

Ardien at https://bugzilla.kernel.org/show_bug.cgi?id=71891 they state "...found in the kernel source file drivers/gpu/drm/radeon/rv770.c. Despite the name this function is used for RV710, RV730 (yours) and RV770.".  So my uneducated guess is that the patch does apply to you.

I can duplicate this problem with CentOS 7.1.

When I run kernel 3.10.0-229.1.2.el7.centos.plus I don't see (or at least notice) the performance issue after resuming from suspend, however I do receive the same errors.  Additionally X will randomly hang (maybe 5% of the time) when I resume, I suspect this may be related to my video card (since those are the only errors I ever see when resuming).

When I run kernel 4.0.0-1.el7.elrepo.x86_64 I do have the performance issue after resuming from suspend (and receive the same errors).  For me I see the huge graphics performance hit when I connect to a Windows 7 PC with xfreerdp.  It's so slow it's unusable.  However if I perform the same xfreerdp connection before I ever suspend/resume my PC it's very fast and responsive.

I found a work around which is to use the "radeon.dpm=0" kernel boot option.  I did this by following these steps:
vi /etc/default/grub
-Append "radeon.dpm=0" to the end of the "GRUB_CMDLINE_LINUX" option:
grub2-mkconfig -o /boot/grub2/grub.cfg

Booting with "radeon.dpm=0" switched me to the "profile" pm method as shown with this command:
cat /sys/class/drm/card0/device/power_method
profile

With "radeon.dpm=0" I no longer get any error messages and I no longer have any performance issues after resuming from suspend.  Time will tell if it fixes my random hang issue.  I haven't checked yet if there's any noticeable power draw difference.

Below I've pasted some relevant hardware and log info.

My hardware:
Motherboard = GA-790FXTA-UD5/GA-790FXTA-UD5, BIOS F3j
CPU = AMD Phenom II X4 910e Deneb Quad-Core 2.6GHz Socket AM3 65W Desktop Processor 
Video card = Gigabyte Radeon HD 4550 512 MB DDR3 (AMD RV710)

Two pages with useful information related to radeon power management:
https://wiki.archlinux.org/index.php/ATI#Dynamic_power_management
http://www.x.org/wiki/RadeonFeature/#index3h2

grep -i rv7 /var/log/messages
//With kernel 3.10.0-229.1.2.el7.centos.plus
Apr 29 08:18:58 black kernel: [drm:rv730_stop_dpm] *ERROR* Could not force DPM to low
Apr 29 08:18:58 black kernel: [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed
//With kernel 4.0.0-1.el7.elrepo.x86_64, note that the error messages have slightly changed (added "[radeon]")
Apr 29 09:21:49 black kernel: [drm:rv730_stop_dpm [radeon]] *ERROR* Could not force DPM to low
Apr 29 09:22:40 black kernel: [drm:rv770_dpm_set_power_state [radeon]] *ERROR* rv770_set_sw_state failed

glxinfo |grep "OpenGL renderer"
OpenGL renderer string: Gallium 0.4 on AMD RV710

I just realized that another performance issue I had is actually caused by this bug.  This occurs with kernel 3.10.0-229.1.2.el7.centos.plus (and probably all kernels).  After I suspend/resume scrolling in gnome-terminal is very slow.  For example if I 'cat /var/log/messages' then scrolling in gnome-terminal is very jerky.  Likewise scrolling from within vi or less (/var/log/messages is a good way to test) is also painfully slow.  Booting with "radeon.dpm=0" also solves this gnome-terminal scroll problem for me.

I tried with option radeon.dpm=0 and yes the message disappears at resume from sleep.

But on my machine I never noticed graphics slowdown (at least with vlank_mode=0 glxgears). I'm not a consumer of fancy graphics or games.

However what I noticed without that option was buggy scrolling in Firefox (and only Firefox). Sometimes all new tabs took like 5 seconds to unfreeze, and once unfreezed each tab remained responsive. Rather strange. I'll use the laptop for a few days to be sure it no longer happens.

On my machine this only visible thing this radeon.dpm=0 does is to silent the error message at resume from sleep. I see no graphic perf increase (at least with glxgears) and still scrolling issue for the app that had it (assuming it is actually related to graphics).

Same issue on Debian 8 stable, kernel 3.16: two *ERROR*s in kernel log and a notable performance degradation in some games after suspend/resume.

I have tried the proposed patch, it does not help (the recompiled driver still has the same behavior).

It seems that the timeout is too small. A dirty fix replacing rdev->usec_timeout with 1000000 in rv770_send_msg_to_smc (drivers/gpu/drm/radeon/rv770_smc.c) works for me (both *ERROR*s in kernel log disappear, performance returns to normal).

Created attachment 120072 [details] [review]
possible fix

Does this patch help?  You will still get the error messages, but everything else should work.

Yes, the new patch behaves exactly as you describe: I don't see any performance degradation after suspend/resume, although error messages are still present.

Created attachment 120091 [details] [review]
quiet errors

This patch will quiet the errors unless you enable driver debugging.  Apply on top of the previous patch.

As expected, error messages disappear, performance problems do not reappear.

Now with kernel 4.4-rc3 the error messages are gone, but the performance issue is still present (glxgears: ~440 FPS before suspend, ~180 FPS after).

I was able to resolve the FPS drop by running the following two commands:

echo battery > /sys/class/drm/card0/device/power_dpm_state
echo balanced > /sys/class/drm/card0/device/power_dpm_state

(In reply to Thaddaeus Tintenfisch from comment #22)
> I was able to resolve the FPS drop by running the following two commands:
> 
> echo battery > /sys/class/drm/card0/device/power_dpm_state
> echo balanced > /sys/class/drm/card0/device/power_dpm_state

In this case, I guess this now becomes bug 66963

-- 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/463.