Comme=
nt # 37
on bug 10232=
2
from dwagner
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 playi=
ng a
video with a deliberately lowered frame rate:
"mpv --no-correct-pts --fps=3D3 --ao=3Dnull some_arbitrary_video.webm=
"
This led me to assume this bug might be caused by the dynamic power managem=
ent,
that often ramps performance up/down when a video is played at such a low f=
rame
rate.
And indeed, I found this confirmed by many experiments: If I use a script l=
ike
> #!/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 anymor=
e -
also with the "low frame rate video test".
So it seems that the transition from one "dpm" performance level =
to another,
with a certain probability, causes these crashes. And the more often the
transitions occur, the sooner one will experience them.
(BTW: For unknown reason, invoking "xrandr" or enabling a monitor=
after sleep
causes the above settings to get lost, so one has to invoke above script
again.)