Bug 82428 - [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU
Summary: [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-10 18:52 UTC by Grzegorz Kowal
Modified: 2015-06-17 10:01 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Possible fix (1.80 KB, patch)
2014-08-11 14:42 UTC, Christian König
Details | Splinter Review
kernel trace (127.59 KB, text/plain)
2015-06-17 08:07 UTC, Yurii Kolesnykov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Grzegorz Kowal 2014-08-10 18:52:58 UTC
With mesa from today's git repository I am getting hard system lockups while trying to play a movie with mplayer/mpv configured to use hardware acceleration (vdpau).

I was able to bisect the commit causing those lockups. The responsible commit is 	1c03a690bfc3265c7fefa7f87e69782a6672a9b2 "radeonsi: use gpu_address from r600_resource".

There is no related message in the logs, since the lockup is immediate and hard reset is required.

I use libdrm, glamour, mesa, and xf86-video-ati from today's git with xorg-server-1.15.0; mpv-0.3.11 with libav-9.14 and libvdpau-0.7.
Comment 1 Grzegorz Kowal 2014-08-10 21:12:46 UTC
I should also mention that I use kernel 3.14.16.
Comment 2 smoki 2014-08-11 08:15:09 UTC
 Same for me with current mesa git on Athlon 5350. xserver 1.16, mpv 0.4.3, libav 10.3, vdpau-0.7 and kernel 3.16.0.
Comment 3 Christian König 2014-08-11 08:18:15 UTC
Going to take a look as soon as I have time.
Comment 4 Christian König 2014-08-11 14:42:56 UTC
Created attachment 104443 [details] [review]
Possible fix

That patch should do the trick. Please test.
Comment 5 smoki 2014-08-11 15:41:26 UTC
(In reply to comment #4)
> Created attachment 104443 [details] [review] [review]
> Possible fix
> 
> That patch should do the trick. Please test.

 Works for me, thanks Christian.
Comment 6 Andy Furniss 2014-08-11 16:56:19 UTC
(In reply to comment #4)
> Created attachment 104443 [details] [review] [review]
> Possible fix
> 
> That patch should do the trick. Please test.

Will test more tonight, but I managed to crash without uvd (just -vo vdpau) last night - though my mplayer also had some issues.

I am not sure something that only touches uvd is enough, but I haven't got time to test now.
Comment 7 Kai 2014-08-11 16:59:50 UTC
(In reply to comment #4)
> Created attachment 104443 [details] [review]
> Possible fix
> 
> That patch should do the trick. Please test.

You can have my
  Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org>
on this. I saw the same issue without the patch.

(In reply to comment #6)
> (In reply to comment #4)
> > Created attachment 104443 [details] [review]
> > Possible fix
> > 
> > That patch should do the trick. Please test.
> 
> Will test more tonight, but I managed to crash without uvd (just -vo vdpau)
> last night - though my mplayer also had some issues.

I had the same behaviour. With the patch from attachment 104443 [details] [review] applied though, everything is back to normal again.
Comment 8 Marek Olšák 2014-08-11 18:02:30 UTC
(In reply to comment #4)
> Created attachment 104443 [details] [review] [review]
> Possible fix
> 
> That patch should do the trick. Please test.

Sorry about that.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Comment 9 Andy Furniss 2014-08-11 18:58:10 UTC
(In reply to comment #7)
> (In reply to comment #4)

> > Will test more tonight, but I managed to crash without uvd (just -vo vdpau)
> > last night - though my mplayer also had some issues.
> 
> I had the same behaviour. With the patch from attachment 104443 [details] [review]
> [review] applied though, everything is back to normal again.

Yes, tested now and the patch does fix for it me.
Comment 10 Grzegorz Kowal 2014-08-11 20:00:08 UTC
No lockups for me after applying the patch. Thanks!
Comment 11 Christian König 2014-08-12 10:09:17 UTC
Just pushed the patch upstream. Thanks for the help.
Comment 12 Yurii Kolesnykov 2015-06-17 08:07:41 UTC
Created attachment 116549 [details]
kernel trace
Comment 13 Yurii Kolesnykov 2015-06-17 08:08:27 UTC
Same hardware, same situation. Random lockups when I start to play video with VDPAU acceleration.
Comment 14 Yurii Kolesnykov 2015-06-17 08:10:34 UTC
OS: ArchLinux
ffmpeg 1:2.7-1
libvdpau 1.1-1
mesa 10.6.0-1
mesa-vdpau 10.6.0-1
mplayer 37379-3
vdpauinfo 1.0-1
Comment 15 Andy Furniss 2015-06-17 09:41:59 UTC
Can you reproduce this with mpv?

What do you need to do with mplayer to produce - how often/when does it crash eg. at start or after a while.

If you can't reproduce with mpv eg.

mpv --hwdec=vdpau --vo=vdpau .....

I already have a bug open that could be a better match.

Also does the kernel output vary between crashes?
Comment 16 Andy Furniss 2015-06-17 09:44:54 UTC
(In reply to Andy Furniss from comment #15)
> Can you reproduce this with mpv?
> 
> What do you need to do with mplayer to produce - how often/when does it
> crash eg. at start or after a while.
> 
> If you can't reproduce with mpv eg.
> 
> mpv --hwdec=vdpau --vo=vdpau .....
> 
> I already have a bug open that could be a better match.
> 
> Also does the kernel output vary between crashes?

Oops I see you already said "when I start to play" - this is my bug  -

https://bugs.freedesktop.org/show_bug.cgi?id=83998
Comment 17 Christian König 2015-06-17 10:01:47 UTC
(In reply to Yuriy Kolesnikov from comment #13)
> Same hardware, same situation. Random lockups when I start to play video
> with VDPAU acceleration.

Witch is clearly a different bug than described in this report. Please open up a new bug report.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.