RX 480 with mesa git etc. Running this gstreamer pipeline gst-launch-1.0 -e filesrc location=big_buck_bunny_720p_1mb.mp4 ! qtdemux ! decodebin ! videoconvert ! omxh264enc ! h264parse ! matroskamux ! filesink location=/tmp/output.mkv works fine on 4.7. On 4.8-rc1 running it a couple of times randomly locks up the gst-launch process. Then while it hangs, running glxgears or so locks up everything. On the plus side, when it works, it works a lot quicker on 4.8. I'll look into bisecting unless someone else can reproduce and already knows why it happens.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.