[Bug 201763] amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0!

bugzilla-daemon at bugzilla.kernel.org bugzilla-daemon at bugzilla.kernel.org
Thu Nov 19 10:43:13 UTC 2020


https://bugzilla.kernel.org/show_bug.cgi?id=201763

Vadim Yanitskiy (vyanitskiy at sysmocom.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vyanitskiy at sysmocom.de

--- Comment #12 from Vadim Yanitskiy (vyanitskiy at sysmocom.de) ---
Hello all,

I have a DELL Inspiron 5547 with Radeon R7 M256:

03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT
[Radeon R7 M260/M265 / M340/M360 / M440/M445 / 530/535 / 620/625 Mobile]

I never experienced any lockups with it, most likely because I was running
quite old kernel most of the time.  About a year ago, I started to use Arch
Linux (thus more or less recent kernels), and also started to see these
messages too:

[ 3916.822707] amdgpu: can't get the mac of 5
[ 3916.824691] amdgpu: VBIOS did not find boot engine clock value in dependency
table. Using Memory DPM level 0!
[ 3923.082543] amdgpu: VI should always have 2 performance levels

It's not like they indicate any problems, the GPU actually works: with hashcat
and proprietary OpenCL run-time on top of open source amdgpu driver I get
nearly the same performance as under Windows; and even OpenGL/Vulkan rendering
seems to work (although performance is significantly worse compared to Intel
Graphics).  Even though I use Intel Graphics most of the time, I was always
interested to investigate the cause of those warnings.

I had a quick look at the kernel's code, and from what I can see they are all
related to the power management (powerplay).  I patched and compiled my own
kernel to get a bit more information, and here is what I managed to understand:

> [ 3916.822707] amdgpu: can't get the mac of 5

According to 'drivers/gpu/drm/amd/powerplay/inc/smumgr.h', the 'mac 5'
corresponds to SMU_MAX_LEVELS_VDDGFX.  This value is neither handled in
iceland_get_mac_definition(), nor it's defined in
'drivers/gpu/drm/amd/powerplay/inc/smu71.h'.  For other GPU families this
constant is used in '*_Discrete_DpmTable', while in 'SMU71_Discrete_DpmTable' I
could not find anything related to VDDGFX.  Therefore I guess this GPU family
(Iceland, SMU71) does not support this kind of power control.

> [57695.583784] amdgpu: VBIOS did not find boot engine clock value in
> dependency table. Using Memory DPM level 0!

This is something I would love to investigate further, but unfortunately have
no time.  The warning itself comes from iceland_populate_smc_boot_level()
defined in 'drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c'.  This
function attempts to get initial clock levels for Graphics DPM and Memory DPM
from VBIOS.

Since we see only one warning, it successfully gets the clock value for
Graphics DPM, but not for Memory DPM.  The function attempts to find value
'data->vbios_boot_state.mclk_bootup_value' in table
'data->dpm_table.mclk_table', which in its turn is populated by
iceland_populate_all_memory_levels().  I need to add some more debug statements
to see the contents of this table and the value that is attampted to be found
in it.

> [ 3923.082543] amdgpu: VI should always have 2 performance levels

I patched the kernel to provide more details in this message, so:

> [ 5312.502812] amdgpu: VI should always have 2 performance levels, however 1
> was detected

This one comes from smu7_apply_state_adjust_rules() defined in
'drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c'.  As far as I can see, the
code is able to handle values !=2, and in some pleces I see checks like ==1, I
most likely this warning can be safely ignored.

As I conclusion, I would say that none of those warnings is critical.

P.S. I am not a kernel developer, and neither I am familiar with amdgpu code
base.  Just had some spare time :)

Best regards,
Vadim.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the dri-devel mailing list