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.
Are there any playback problems?
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.
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.
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.
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.
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?
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.