Comme=
nt # 39
on bug 10232=
2
from Andrey Grodzovsky
(In reply to dwagner from comment #37)
> In the related bug report
> (https://bugs.freedesktop.org/show_bug.=
cgi?id=3D107152) I noticed that this
> bug can be triggered very reliably and quickly by playing a video with=
a
> deliberately lowered frame rate:
> "mpv --no-correct-pts --fps=3D3 --ao=3Dnull some_arbitrary_video=
.webm"
>=20
> This led me to assume this bug might be caused by the dynamic power
> management, that often ramps performance up/down when a video is playe=
d at
> such a low frame rate.
I tried exactly the same - reproduce with same card model and latest kernel=
and
run webm clip with mpv same way you did and it didn't happen.=20
>=20
> And indeed, I found this confirmed by many experiments: If I use a scr=
ipt
> like
> > #!/bin/bash
> > cd /sys/class/drm/card0/device
> > echo manual >power_dpm_force_performance_level
> > # low
> > echo 0 >pp_dpm_mclk=20
> > echo 0 >pp_dpm_sclk
> > # medium
> > #echo 1 >pp_dpm_mclk=20
> > #echo 1 >pp_dpm_sclk
> > # high
> > #echo 1 >pp_dpm_mclk=20
> > #echo 6 >pp_dpm_sclk
> to enforce just any performance level, then the crashes do not occur a=
nymore
> - also with the "low frame rate video test".
>=20
> So it seems that the transition from one "dpm" performance l=
evel to another,
> with a certain probability, causes these crashes. And the more often t=
he
> transitions occur, the sooner one will experience them.
>=20
> (BTW: For unknown reason, invoking "xrandr" or enabling a mo=
nitor after
> sleep causes the above settings to get lost, so one has to invoke above
> script again.)