[Ryzen 3400G] [drm] REG_WAIT timeout 10us * 200000 tries - rv1_vbios_smu_send_msg_with_param line:82

As we look into this more we are not seeing this with 5.0.0-40-generic and therefore feels like a regression.

ii  libdrm-amdgpu1:amd64                       2.4.99-1ubuntu1~18.04.2                          amd64        Userspace interface to amdgpu-specific kernel DRM services -- runtime
ii  xserver-xorg-video-amdgpu                  18.0.1-1

$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD RAVEN (DRM 3.27.0, 5.0.0-40-generic, LLVM 9.0.0) (0x15d8)
    Version: 19.2.8
    Accelerated: yes
    Video memory: 2048MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 4.5
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 1063 MB, largest block: 1063 MB
    VBO free aux. memory - total: 3035 MB, largest block: 3035 MB
    Texture free memory - total: 1063 MB, largest block: 1063 MB
    Texture free aux. memory - total: 3035 MB, largest block: 3035 MB
    Renderbuffer free memory - total: 1063 MB, largest block: 1063 MB
    Renderbuffer free aux. memory - total: 3035 MB, largest block: 3035 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 2048 MB
    Total available memory: 5120 MB
    Currently available dedicated video memory: 1063 MB
OpenGL vendor string: X.Org
OpenGL renderer string: AMD RAVEN (DRM 3.27.0, 5.0.0-40-generic, LLVM 9.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.8
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.2.8
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Can you bisect?

I'm trying to bisect this but it seems like I'm hitting a different bug altogether on these earlier kernels:

[drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing A4DE (len 84, WS 0, PS 0) @ 0xA514
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing D040 (len 525, WS 0, PS 0) @ 0xD091

I'm not getting the same warning ([drm] REG_WAIT timeout 10us * 200000 tries - rv1_vbios_smu_send_msg_with_param line:82) that I get on newer kernels, is it safe to assume that this is not the same bug? Should I only mark a commit as bad if I get a similar warning? dmesg-5.0.0-07085-gb5dd0c658c.log

yeah, assume it's bad if you hit the same error.

I think I figured out why I'm not hitting that error, it's because that specific function (rv1_vbios_smu_send_msg_with_param) was only added between 5.2 and 5.3 in commit baa1fd7f32f23118f067b5af79b53998a617ef17 and c69dd2d06cdfb1bb8c6cd0ebfb3cc1e502b9de3a, I'm still getting the same symptoms on 5.2 that I described in #1131 (closed) even though I'm not getting the same warning. I think this is the same bug after all.

dmesg-5.2.0.log

I don't think this is related but after staring at this function for a while I think there's a mistake here:

int rv1_vbios_smu_set_dispclk(struct clk_mgr_internal *clk_mgr, int requested_dispclk_khz)
{
	int actual_dispclk_set_mhz = -1;
	struct dc *dc = clk_mgr->base.ctx->dc;
	struct dmcu *dmcu = dc->res_pool->dmcu;

	/*  Unit of SMU msg parameter is Mhz */ // According to this
	actual_dispclk_set_mhz = rv1_vbios_smu_send_msg_with_param(
			clk_mgr,
			VBIOSSMC_MSG_SetDispclkFreq,
			requested_dispclk_khz / 1000);

	/* Actual dispclk set is returned in the parameter register */
	actual_dispclk_set_mhz = REG_READ(MP1_SMN_C2PMSG_83) * 1000; // This register should already be in Mhz so by multiplying by 1000 this is actually in khz

	if (!IS_FPGA_MAXIMUS_DC(dc->ctx->dce_environment)) {
		if (dmcu && dmcu->funcs->is_dmcu_initialized(dmcu)) {
			if (clk_mgr->dfs_bypass_disp_clk != actual_dispclk_set_mhz) // I think dfs_bypass_disp_clk is in khz so comparing to Mhz is wrong although actual_dispclk_set_mhz is actually in khz
				dmcu->funcs->set_psr_wait_loop(dmcu,
						actual_dispclk_set_mhz / 7); // Looking at the other usage of set_psr_wait_loop I think this should be Mhz but since actual_dispclk_set_mhz is in khz this is wrong
		}
	}

	return actual_dispclk_set_mhz * 1000; // I don't think this return value is being used but this is returning hz since actual_dispclk_set_mhz is in khz
}

I tried the workaround posted by Michel in #1146 (closed) and it's been 3 days since I last encountered this bug, whereas before it takes less than 5 minutes of gaming on kernel 5.6 before it happens.

I looked into the workaround as well and the following udev rule seems to workaround the bug.

/etc/udev/rules.d/30-amdgpu-pm.rules

KERNEL=="card0" SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="manual", ATTR{device/pp_power_profile_mode}="4"

In particular, when we experience this, we see

$ cat /sys/devices/pci0000\:00/*/*/pp_dpm_sclk
0: 200Mhz
1: 62915360Mhz *
2: 1400Mhz

or

$ cat /sys/devices/pci0000\:00/*/*/pp_dpm_sclk
0: 200Mhz 
1: 0Mhz *
2: 1400Mhz

changed the description

This issue hasn't had any activity since 2020-06-02. The AMD driver stack changes rapidly and contains lots of shared code across products so it's possible that it has already been fixed. Please upgrade to a current stable kernel and userspace stack and try again. If you still experience this issue with the latest driver stack, please capture relevant logging and open a new issue referring back to this one.

closed

changed the description

[Ryzen 3400G] [drm] REG_WAIT timeout 10us * 200000 tries - rv1_vbios_smu_send_msg_with_param line:82

Designs

Child items ...

Activity

Admin message

[Ryzen 3400G] [drm] REG_WAIT timeout 10us * 200000 tries - rv1_vbios_smu_send_msg_with_param line:82

Activity