Bug 81444

Summary: [drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!
Product: DRI Reporter: Harald Judt <h.judt>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Possible fix. none

Description Harald Judt 2014-07-16 21:06:13 UTC
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950]

I get these messages after using UVD for some time. First I thought this would only be a problem in kdenlive, which uses mlt which has vdpau support. But it also is a problem when playing videos in e.g. smplayer.

switching from power state:
    ui class: performance
    internal class: none
    caps:
    uvd    vclk: 0 dclk: 0
        power level 0    sclk: 25000 mclk: 15000 vddc: 900 vddci: 950
        power level 1    sclk: 50000 mclk: 125000 vddc: 1000 vddci: 1150
        power level 2    sclk: 80000 mclk: 125000 vddc: 1060 vddci: 1150
    status: c
switching to power state:
    ui class: none
    internal class: uvd
    caps: video
    uvd    vclk: 54000 dclk: 40000
        power level 0    sclk: 50000 mclk: 125000 vddc: 1000 vddci: 1150
        power level 1    sclk: 50000 mclk: 125000 vddc: 1000 vddci: 1150
        power level 2    sclk: 72500 mclk: 125000 vddc: 1060 vddci: 1150
    status: r
[drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!
switching from power state:
    ui class: none
    internal class: uvd
    caps: video
    uvd    vclk: 54000 dclk: 40000
        power level 0    sclk: 50000 mclk: 125000 vddc: 1000 vddci: 1150
        power level 1    sclk: 50000 mclk: 125000 vddc: 1000 vddci: 1150
        power level 2    sclk: 72500 mclk: 125000 vddc: 1060 vddci: 1150
    status: c
switching to power state:

I believe I saw this error first in linux-3.14 and not in 3.13, but I don't know whether this is a regression or not. Though I think 3.13 worked fine.

There are no more related error messages to be found in dmesg.
I'm using git libdrm and mesa.
Comment 1 Alex Deucher 2014-07-16 21:26:18 UTC
Are there any playback problems?
Comment 2 Harald Judt 2014-07-16 21:39:18 UTC
Yes, before the error occurred, I noticed playback was a bit jerky and seemed stuck sometimes for short whiles. It stabilized after skipping forward/backward. With xv output, playback was jerky too, but there more problems with vdpau. That was yesterday.

I've noticed the error today after resuming from hibernation. Playback seemed to work once but was jerky again, so I tried to change settings, and suddenly mplayer crashed. After that I noticed the error in dmesg and had to reboot the machine to get video playback going again. After the reboot, both xv and vdpau work fine.
Comment 3 Harald Judt 2014-08-01 05:29:10 UTC
I believe the playback issues may not be related to the -22 error. I've downgraded ffmpeg from 2.3 to 2.2.5, and the choppiness and issues both with xv and vdpau seem solved, so this was very likely a software problem (long-time test still pending).

I will try to reproduce the -22 error in one or two weeks, using kdenlive with mlt (with vdpau support) seemed to have been a certain way to make it happen pretty fast.
Comment 4 Christian König 2014-08-01 08:54:19 UTC
Well, radeon_uvd_free_handles is only called if an application crashed or didn't cleaned up the VDPAU driver correctly. (e.g. the kernel needs to manually tell the hardware that a decoder isn't needed any more because the application failed to do so).

So it's definately some kind of userspace problem involved here.

But neverless there is also something wrong with the kernel function, otherwise you won't get -22 (-EINVAL) in your dmesg.
Comment 5 Harald Judt 2014-08-01 08:59:26 UTC
Yes, there must be something else wrong (I guess in kernel) because VDPAU stops working when the error has occurred. I'll try to find a scenario which is easy to reproduce.
Comment 6 Christian König 2014-08-22 12:46:56 UTC
Created attachment 105100 [details] [review]
Possible fix.

I've figured out what's going wrong here. You somehow used up all you video memory and we don't try hard enough on destroying the UVD session to swap something out to make room for the necessary hardware message.

The attached patch on top of Alex drm-next-3.18-wip branch should fix the problem.

Only the question how did you managed to do so remains?
Comment 7 Harald Judt 2014-08-28 22:45:58 UTC
After pulling from drm-next-3.18-wip into 3.16 and applying the patch, I haven't seen the issue (error -22) again. In general, UVD playback seems more stable now. Earlier, smplayer would suddenly and for some unknown reason start playing the video twice as fast, with the audio playing normally. This issue is gone too, though I can't tell whether this is because of upgrading to 3.16.0 or because of other changes.

With kdenlive I experience a lot of crashes when media-libs/mlt is built with vdpau support, though. These crashes do not happen when not using vdpau. I'm not sure why they happen, perhaps because of using "non-standard" video sizes for input files. I will try to get a gdb backtrace, but I guess that will be better posted at another place (or at least in another bug report)?

So far, it seems fixed for me, I'll reopen otherwise. Thanks for the patch.

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.