Bug 73788 - [Radeon HD 7770 GHz Edition] Cape Verde XT: DPM set state failed
Summary: [Radeon HD 7770 GHz Edition] Cape Verde XT: DPM set state failed
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-01-19 09:32 UTC by Stepan Bakshaev
Modified: 2019-11-19 08:41 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (75.88 KB, text/plain)
2014-01-19 09:32 UTC, Stepan Bakshaev
no flags Details
xorg.log (94.11 KB, text/plain)
2014-01-19 09:33 UTC, Stepan Bakshaev
no flags Details

Description Stepan Bakshaev 2014-01-19 09:32:52 UTC
Created attachment 92378 [details]
dmesg

I got in dmesg

[drm:si_dpm_set_power_state] *ERROR* si_set_sw_state failed

I have low fps in Team Fortress 2. There are 15-30 fps. cpu governor is performance. All settings are low and 1920 res. If I use catalyst I got more then 120 at high settings.
Comment 1 Stepan Bakshaev 2014-01-19 09:33:58 UTC
Created attachment 92379 [details]
xorg.log
Comment 2 Hohahiu 2014-01-19 18:12:18 UTC
I can confirm this bug. It also happens on mine 7750M.
Comment 3 Stepan Bakshaev 2014-01-20 17:58:12 UTC
Unigine Sanctuary on Cape Verde XT:
    At present: 30 fps

Unigine
Sanctuary demo
benchmark edition v2.3
FPS: 29.9
Scores: 1267
Min FPS: 26.9
Max FPS: 31.8

Hardware
Binary:	Linux 32bit GCC 4.3.2 Release May 20 2010
Operating system: Linux 3.13.0-4-generic x86_64
CPU model: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
CPU flags: 3392MHz MMX SSE SSE2 SSE3 SSSE3 SSE41 SSE42 HTT
GPU model: Gallium 0.4 on AMD CAPE VERDE 3.0 Mesa 10.0.1 256Mb

Settings
Render: opengl
Mode: 1920x1080 fullscreen
Shaders: high
Textures: high
Filter: trilinear
Anisotropy: 4x
Translucence: enabled
Parallax: enabled
Reflection: enabled
DOF:	disabled
HDR:	disabled

Vsync is disabled.

Temp grows from 37 to 59.
Comment 4 Alex Deucher 2014-01-20 23:24:53 UTC
Is this a regression?  Was dpm working previously at some point, if so when?
Comment 5 Stepan Bakshaev 2014-01-21 09:38:04 UTC
(In reply to comment #4)
> Is this a regression?  Was dpm working previously at some point, if so when?

Alex, I want to check this. What should I start from? You added si_dpm.c at 2013-06-27 (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/gpu/drm/radeon/si_dpm.c?showmsg=1). Were there another system to change power management before? Is it enought to find first stable version available in ubuntu repo with si_dpm.c? Or should I use kernel from git and start bisect by history of si_dpm.c?
Comment 6 Arek Ruśniak 2014-01-21 19:05:05 UTC
3.12.8 looks good. 3.13rc2 gives me this message on cape verde xt, I couldn't build&test rc1 (don't know why)
Comment 7 Hohahiu 2014-01-22 01:36:20 UTC
(In reply to comment #4)
> Is this a regression?  Was dpm working previously at some point, if so when?

It worked fine in 3.11 and 3.12. The problem appeared somewhere during the development of 3.13. At those point vgaswitcheroo didn't work and I had to stick to older versions of the kernel.
Comment 8 Stepan Bakshaev 2014-01-22 16:25:01 UTC
I installed kernel from here http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-trusty/

and try to change power_method by http://xorg.freedesktop.org/wiki/RadeonFeature/#kmspowermanagementoptions

root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# uname -a
Linux silverstone 3.12.0-031200-generic #201311071835 SMP Thu Nov 7 23:36:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.12.0-031200-generic root=UUID=4d025cce-1bf0-466f-a5c3-501d3f548e70 ro quiet splash vt.handoff=7 radeon.dpm=1

root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# echo "dynpm" > power_method 
bash: echo: write error: Invalid argument
root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# echo "profile" > power_method 
bash: echo: write error: Invalid argument
root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# cat power_method 
dpm

root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# echo "high" > power_profile 
bash: echo: write error: Invalid argument
root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# cat power_profile 
default

root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# dmesg | grep 'drm.*error'

root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# cat class 
0x030000
root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# cat vendor 
0x1002
root@silverstone:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0# cat device 
0x683d

There are no errors and no success in changing power_method. Where did I do mistake?
Comment 9 Stepan Bakshaev 2014-01-22 16:33:06 UTC
Return to 3.13

root@silverstone:/sys/class/drm/card0/device# uname -a
Linux silverstone 3.13.0-5-generic #20-Ubuntu SMP Mon Jan 20 19:56:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
root@silverstone:/sys/class/drm/card0/device# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.13.0-5-generic root=UUID=4d025cce-1bf0-466f-a5c3-501d3f548e70 ro quiet splash vt.handoff=7 radeon.dpm=1

root@silverstone:/sys/class/drm/card0/device# echo "dynpm" > power_method 
bash: echo: write error: Invalid argument
root@silverstone:/sys/class/drm/card0/device# cat power_method 
dpm

root@silverstone:/sys/class/drm/card0/device# echo "high" > power_profile 
bash: echo: write error: Invalid argument

root@silverstone:/sys/class/drm/card0/device# dmesg | grep -i "drm.*error"
[   13.800555] [drm:si_dpm_set_power_state] *ERROR* si_set_sw_state failed

root@silverstone:/sys/class/drm/card0/device# cat vendor 
0x1002
root@silverstone:/sys/class/drm/card0/device# cat device 
0x683d
Comment 10 Alex Deucher 2014-01-22 16:37:25 UTC
(In reply to comment #7)
> (In reply to comment #4)
> > Is this a regression?  Was dpm working previously at some point, if so when?
> 
> It worked fine in 3.11 and 3.12. The problem appeared somewhere during the
> development of 3.13. At those point vgaswitcheroo didn't work and I had to
> stick to older versions of the kernel.

Any chance you could bisect?
Comment 11 Alex Deucher 2014-01-22 16:39:55 UTC
(In reply to comment #8)
> 
> There are no errors and no success in changing power_method. Where did I do
> mistake?

We don't support changing between dpm and the older methods dynamically.  When you enable dpm, you can't switch to the older pm methods.
Comment 13 Arek Ruśniak 2014-01-24 13:07:44 UTC
in my case it's error message in dmesg output only, performance is pretty the same.

kernel ver.	 3.13 vs 12.8
lightsmark	245,42	245,84
unigine:
valley		17,55	17,5
sanctuary	65,64	65,63
gputest:
plot3D		16603	16555
furmark		1519	1520
triangle	96610	96541
pix. piano	127	127
pix. volplosion	1060	1060

powered by pts :)
 
hardware: i5-4670 + 8GB + radeon hd7770 + display@1680x1050
software: archlinux 64b/mesa-git-00c6720/llvm-svn-199943/ddx&glamor-8 days old/xserver-1.15/gnome3
Comment 14 Alex Deucher 2014-01-24 15:09:31 UTC
(In reply to comment #12)
> Alex it's here:
> 
> http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.13-
> wip&id=4573388c92ee60b4ed72b8d95b73df861189988c

Does reverting that commit fix the problem?
Comment 15 Arek Ruśniak 2014-01-24 17:44:18 UTC
yes it does. dmesg doesn't show "[drm:si_dpm_set_power_state] *ERROR* si_set_sw_state failed".
i've tested it on mainline tree
Comment 16 Stepan Bakshaev 2014-01-25 15:53:41 UTC
1) checkout git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
2) revert 4573388c92ee60b4ed72b8d95b73df861189988c
3) no error `si_set_sw_state failed`
Comment 17 Martin Peres 2019-11-19 08:41:54 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/426.


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.