Bug 67970

Summary:	Kernel bugs related to the powersaving features of mobility radeon x1400
Product:	DRI	Reporter:	Keivan <shayanmansuri>
Component:	DRM/Radeon	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED MOVED	QA Contact:
Severity:	blocker
Priority:	medium	CC:	mar.kolya
Version:	XOrg git
Hardware:	All
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Keivan 2013-08-10 03:34:02 UTC

I have a Mobility Radeon X1400 (RV500 Family) on my dell inspiron 6400 (or it's called inspiron 1501 or 1505 elsewhere). I use Open-source drivers and they work for me and I have no problem with anything except the powermanagement at kernel level.

When I want to activate powersaving feature I use these commands:

1. when I use this command:
echo dynpm > /sys/class/drm/card0/device/power_method

nothing happens. I mean GPU frequency remain high. I even do not use a GUI. I'm in the shell.

2. when I use these commands
echo profile > /sys/class/drm/card0/device/power_method
echo low > /sys/class/drm/card0/device/power_profile

I receive these error:
kernel:[ 192.253008] NMI: PCI system error (SERR) for reason b1 on CPU 0.
kernel:[ 192.253016] Dazed and confused, but trying to continue

I have noticed that the kernel do not changes the GPU and Vram frequencies correctly in the profile mode.

This is what I get when I set it to mid:
# echo mid > /sys/class/drm/card0/device/power_profile
# cat /sys/kernel/debug/dri/0/radeon_pm_info

default engine clock: 432000 kHz
current engine clock: 209250 kHz
default memory clock: 396000 kHz
current memory clock: 135000 kHz
PCIE lanes: 1

This is what I get when I set it to low:
# echo low > /sys/class/drm/card0/device/power_profile
# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 432000 kHz
current engine clock: 324000 kHz
default memory clock: 396000 kHz
current memory clock: 135000 kHz
PCIE lanes: 1

This is what I get when I set it to high:
# echo high > /sys/class/drm/card0/device/power_profile
# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 432000 kHz
current engine clock: 432000 kHz
default memory clock: 396000 kHz
current memory clock: 396000 kHz
PCIE lanes: 0

If you look at the above values, it is obvious that the current clock of mid and low profiles should be replaced with each other.

I've tested this in different distribution of GNU/Linux with different kernel versions: Including Ubuntu, LMDE, Archlinux and Chakra. with these kernel versions: 2.6.38, 2.6.39, 3.0.0 RC5, 3.0.0-1-amd64 in LMDE, and lately with 3.4.55 LTS in ubuntu 12.04.2.

Comment 1 Boris Gjenero 2016-10-20 22:48:58 UTC

I've seen the same things on my Inspiron 6400 with Radeon X1400 graphics, running 64-bit Ubuntu 16.10 with kernel 4.8.0-26-generic. Though while playing with it I saw some variations in behaviour. Sometimes in dynpm, reported frequencies were from the last profile that was used. Sometimes, changing a profile had no effect. Using vblank_mode=0 glxgears, Chrome and Firefox I am unable to see a performance difference between low and mid. There is a very definite difference between those and high profile. Performance of dynpm and high profile is identical or very close.

Playing with these settings can introduce instability. After switching among profiles, going back to dynpm usually causes brief bright flashes of the screen. Those flashes never happen after setting dynpm in /etc/rc.local. Also, changing to high profile caused a total hang once, where even Magic SysRq didn't help. Yes, I also see NMIs switching to low, but those seem to have no ill effect.

Comment 2 Martin Peres 2019-11-19 08:37:03 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/366.

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.