Created attachment 107947 [details] dmesg output with no CPU stuck messages This bug report is for the problem described here: http://www.phoronix.com/forums/showthread.php?107724-Upgrade-to-Kaveri-very-slow-VDPAU-performance I'm using an A10-7800 and openSUSE 13.2 with Kernel 3.17.0. Most of the times I get a lot of CPU stuck messages while booting and it takes several minutes until the system is booted to X. I added the log output with drm.debug=2. Sometimes there are no CPU stuck messages and the system is booting fast. If I blacklist the radeon driver or boot with nomodeset the system is working without CPU stuck messages everytime. Also it seems that the GPU is running always on the lowest power state, cat /sys/kernel/debug/dri/0/radeon_pm_info is giving me always the same, while being idle, running VDPAU programs, running qvdpautest or glxgears (withut vsync): power level 0 sclk: 35122 vddc: 4900 So OpenGL applications and VDPAU is working very slow. The dmesg output of a successfull boot and of a boot with CPU stuck messages is attached, both times with drm.debug=2. Also Xorg.0.log is attached.
Created attachment 107948 [details] journalctl --dmesg of boot with CPU stuck messages
Created attachment 107954 [details] Xorg.0.log
Can you attach the dmesg output with radeon.dpm=1 on the kernel command line? Does booting with radeon.bapm=0 make any difference?
Created attachment 107964 [details] dmesg output with drm.debug=2 radeon.bapm=0 radeon.dpm=1 radeon.bapm=0 makes a big difference, there seems to be no more cpu stuck bugs und booting is really fast. But the performance problem persists. I have added the dmesg output using radeon.dpm=1 and radeon.bapm=0. If needed I will try to get it without radeon.bapm=0
Do the clocks ever change? E.g., try running vblank_mode=0 glxgears and while it is running check the clocks in /sys/kernel/debug/dri/0/radeon_pm_info What is the value of: /sys/class/drm/card0/device/power_dpm_force_performance_level As root try: echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level Does that make a difference?
As written in the first comment the clocks never change. Running vblank_mode=0 glxgears does not change the clocks, also echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level makes no difference to the values. The initial value of /sys/class/drm/card0/device/power_dpm_force_performance_level is "auto".
does setting radeon.bapm=0 change anything with respect to the GPU clocks?
no it does only "fix" the CPU stuck errors
Today I tried to use radeon.dpm=0 to get the full performance, but I noticed that with radeon.dpm=0 I get the CPU stuck errors again, even with radeon.bapm=0. So the only way to boot without these errors is "radeon.bapm=0" or "radeon.bapm=0 radeon.dpm=1".
Using linux-next, the output of /sys/kernel/debug/dri/0/radeon_pm_info has changed a bit, but none of the problems are solved. running glxgears or idle: uvd disabled vce disabled power level 0 sclk: 35122 vddc: 4900 running qvdpautest: uvd enabled vce disabled power level 0 sclk: 35122 vddc: 4900 So it seems the driver is detecting the vdpau usage but it is not switching the power level.
To check if it is a hardware problem or a problematic bios setting I installed openSUSE 13.1 in parallel, there I was able to test with fglrx. And it is working well, the power management is working and the clock is getting up to the max when running glxgears (tested with aticonfig --odgc). So this has to be a driver bug... Can you give me any hint how I can debug this problem? I'm a software engineer myself (but mostly Java) and can test patches or "play" with the code if you say me where... ;)
Created attachment 108260 [details] [review] disable some dpm features You might try this patch. If it helps try to narrow down which specific features are causing the problem. You might also check your bios configuration and see if any of those settings make a difference. All of the relevant power management code for your asic is in kv_dpm.c and kv_smc.c.
Thanks for the patch. I still need radeon.bapm=0 to boot properly, but with setting pi->enable_nb_dpm = false; the clock is getting higher and so I have the full performance. Finally I can watch HD videos with VDPAU now :) I run this tests using kernel 3.18-rc1. I do not have looked at the code further, that is the consequence of this setting? Could there be any matching BIOS setting? How can I further debug why my system is needing this change?
Created attachment 108473 [details] [review] dpm fix (In reply to Marcel Witte from comment #13) > Thanks for the patch. I still need radeon.bapm=0 to boot properly, but with > setting > > pi->enable_nb_dpm = false; > > the clock is getting higher and so I have the full performance. Finally I > can watch HD videos with VDPAU now :) > Great. The attached patch should allow your system to work out of the box. > I run this tests using kernel 3.18-rc1. I do not have looked at the code > further, that is the consequence of this setting? Could there be any > matching BIOS setting? How can I further debug why my system is needing this > change? nb dpm is northbridge dpm. You might check and see if there are any bios options related to the northbridge that workaround the issue.
-- 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/545.
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.