Bug 97240

Created attachment 125591 [details]
dmesg

Almost forgot dmesg.

I think these messages correspond with the hang:

[   64.406834]
                failed to send pre message 15b ret is 0
[  106.006518]
                failed to send pre message 155 ret is 0

Sounds like a power management problem to me. Could you bisect?

I'm not completely confident that I marked every bad commit, but I got this:

c4120d55ffa44746584a8a1e5b00cb7eafc006ff is the first bad commit
commit c4120d55ffa44746584a8a1e5b00cb7eafc006ff
Author: Christian König <christian.koenig@amd.com>
Date:   Wed Jul 20 14:11:26 2016 +0200

    drm/amdgpu: use begin/end_use for UVD power/clock gating

    This fixes turning power and clock on when it is actually needed.

    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

:040000 040000 6dbab0f2ea26ecf48e88531eee491c2d0ebbc418 8dedcdeeb16e8a4f7a06a8934aaf912469be2171 M      drivers

Also the decodebin element uses vaapi to decode the video, so I may have mischaracterized the bug in the first place that it's really an UVD problem.

(In reply to Christoph Haag from comment #3)

> Also the decodebin element uses vaapi to decode the video, so I may have
> mischaracterized the bug in the first place that it's really an UVD problem.

So does something like below work?

for X in $(seq 1 50); do gst-launch-1.0 -e filesrc location=big_buck_bunny_720p_1mb.mp4 ! qtdemux ! avdec_h264 ! videoconvert ! omxh264enc ! fakesink; done

My Tonga used to have this issue and this post prompted me to look what fixed it =
it was a recent tonga firmware upgrade so not much use to you, also I think power gating for uvd/vce is disabled for tonga - so maybe another difference.

While the issue existed I could work around by forcing my clocks to high when testing vce =

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
 then 
echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level

after testing finished to keep thinks cooler :-) (note that if you change modes or your monitor goes into dpms this will happen anyway)

(In reply to Andy Furniss from comment #4)
> (In reply to Christoph Haag from comment #3)
> 
> > Also the decodebin element uses vaapi to decode the video, so I may have
> > mischaracterized the bug in the first place that it's really an UVD problem.
> 
> So does something like below work?
> 
> for X in $(seq 1 50); do gst-launch-1.0 -e filesrc
> location=big_buck_bunny_720p_1mb.mp4 ! qtdemux ! avdec_h264 ! videoconvert !
> omxh264enc ! fakesink; done

Yes.

> My Tonga used to have this issue and this post prompted me to look what
> fixed it =
> it was a recent tonga firmware upgrade so not much use to you, also I think
> power gating for uvd/vce is disabled for tonga - so maybe another difference.
> 
> While the issue existed I could work around by forcing my clocks to high
> when testing vce =
> 
> echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
>  then 
> echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level
> 
> after testing finished to keep thinks cooler :-) (note that if you change
> modes or your monitor goes into dpms this will happen anyway)

No.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/86.