Created attachment 145=
080 [details]
dmesg with amdgpu.dpm=3D2

> Tom B., did you try booting with amdgpu.dpm=3D1 =
or amdgpu.dpm=3D2 (default is generally -1 for automatic)? Seems like one o=
f those might enable the new experimental SW SMU v11 feature on Vega20 . . =
.

Now that is interesting.dpm=3D-1 is the same as default, and default is 1,
enabled so dpm=3D1 is what we've been using all along. But dpm=3D2 and the =
patch
you linked to are interesting.

I tried it, it didn't help the crashing issue and I was stuck at 30w. As so=
on
as I started sddm the system froze. I've attached my dmesg from amdgpu.dpm=
=3D2
boot. It doesn't fix the issue but it does help answer a few questions I ha=
d:

1. The functions in vega20_ppt.c are used with this new patch so that answe=
rs
my question from earlier, that's what this file is for and why it contains
similar/identical functions.

2. It explains the difference I found in comment 97: This commit
https://github.com/torvalds/linux/commit/94ed6d0cfdb867b=
e9bf05f03d682980bce5d0036
has the new else block for smu_display_configuration_change which we now kn=
ow
is the software version of this function.

More importantly, though, knowing that enabling DPM causes the crash, this
tells us either:

A) The bug is present in both versions of the vega20 code: vega20_hwmgr.c a=
nd
vega20_ppt.c or..

B) The card reaches an invalid state before DPM is initialised and the card=
 is
fine until it receives a DPM change.

Given that two different versions of the code produce the same result, my h=
unch
is that the problem is B. The card is not in a state where it's able to rec=
eive
power changes.