Bug 78297

Summary: Radeon uvd makes VDPAU clients to crash at vlVdpDecoderCreate with 1080p videos
Product: DRI Reporter: Marco Trevisan (Treviño) <mail>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Flash player crash using VDPAU with full-hd videos
none
Flash player crash using VDPAU with full-hd videos
none
VLC crash using VDPAU with full-hd videos
none
dmesg
none
Possible fix. none

Description Marco Trevisan (Treviño) 2014-05-05 11:46:04 UTC
Created attachment 98475 [details]
Flash player crash using VDPAU with full-hd videos

I've enabled VDPAU support in flash player, and testing it with normal youtube videos (up to 720p) gives good results (congrats!).

However, once I switch to 1080p quality, the flash player crashes, and this seems to happen at the mesa vdpau driver level (for reference, this work using Intel, although that's a different story, but I can't test nouveau here).

Anyway, I'm attaching here the backtrace. I've got it using mesa stock from ubuntu, thus I've linked on the bt a paste of the exact files referenced by the debugger.
Let me know if you need further debugging.

This is what happens in Ubuntu 14.04, but the same seems to happens in Arch Linux (check https://bbs.archlinux.org/viewtopic.php?pid=1409666).
Comment 1 Marco Trevisan (Treviño) 2014-05-05 12:54:49 UTC
Created attachment 98480 [details]
Flash player crash using VDPAU with full-hd videos
Comment 2 Christian König 2014-05-05 12:58:43 UTC
What version of mesa is that? From the backtrace it looks like allocating a buffers fails and then we crash because we want to clear the buffer.

But the line numbers look quite outdated to me.
Comment 3 Marco Trevisan (Treviño) 2014-05-05 13:00:22 UTC
Created attachment 98482 [details]
VLC crash using VDPAU with full-hd videos

This is actually more generic than I thought, as it happens also with VLC and Mplayer.

Attaching the VLC backtrace here (very similar to flash and to mplayer).
Comment 4 Marco Trevisan (Treviño) 2014-05-05 13:03:15 UTC
(In reply to comment #2)
> What version of mesa is that? From the backtrace it looks like allocating a
> buffers fails and then we crash because we want to clear the buffer.
> 
> But the line numbers look quite outdated to me.

As said I've used the ubuntu debug version, so in the backtrace (the last one attached, not the one I deprecated) I've linked the relative files:

src/gallium/state_trackers/vdpau/decode.c: http://paste.ubuntu.com/7398157/
src/gallium/drivers/radeon/radeon_uvd.c: http://paste.ubuntu.com/7398148/

I might test this with a more recent version as well, but since this seems to happen in Arch as well, I suppose it's in git version too.
Comment 5 Christian König 2014-05-05 13:24:15 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > What version of mesa is that? From the backtrace it looks like allocating a
> > buffers fails and then we crash because we want to clear the buffer.
> > 
> > But the line numbers look quite outdated to me.
> 
> As said I've used the ubuntu debug version, so in the backtrace (the last
> one attached, not the one I deprecated) I've linked the relative files:
> 
> src/gallium/state_trackers/vdpau/decode.c: http://paste.ubuntu.com/7398157/
> src/gallium/drivers/radeon/radeon_uvd.c: http://paste.ubuntu.com/7398148/
> 
> I might test this with a more recent version as well, but since this seems
> to happen in Arch as well, I suppose it's in git version too.

Source files doesn't help at all, I need a version number or better git hash of what revision this is.

It looks like allocating the decoded picture buffer works, but mapping it returns a NULL pointer. Is there any other error message? Kernel or stderr?
Comment 6 Marco Trevisan (Treviño) 2014-05-05 14:31:32 UTC
(In reply to comment #5)
> Source files doesn't help at all, I need a version number or better git hash
> of what revision this is.

So, as I reported the ubuntu package is based on mesa 10.1, and the same is on debian git, thus the git hash seems to be 4a86465 (and line numbers reported on these backports matches).

The full tree, with ubuntu patches applied, is available at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/mesa/trusty/files (or bzr branch lp:ubuntu/mesa).

> It looks like allocating the decoded picture buffer works, but mapping it
> returns a NULL pointer. Is there any other error message? Kernel or stderr?

Mh, no I'm just getting this (on VLC):

VLC media player 2.1.2 Rincewind (revision 2.1.2-0-ga4c4876)
[0x15adaa8] main interface error: no suitable interface module
[0x13a9148] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
libva info: VA-API version 0.35.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'vdpau'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/vdpau_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0
[0x7f4358c28e98] avcodec decoder: Using VA API version 0.35 for hardware decoding.
Bus Error (core dumped)

And pretty similar on mplayer (http://pastebin.ubuntu.com/7398928/), nothing more kernel side.
Comment 7 Christian König 2014-05-05 14:55:45 UTC
(In reply to comment #6)
> [0x7f4358c28e98] avcodec decoder: Using VA API version 0.35 for hardware
> decoding.
> Bus Error (core dumped)

Oh! Well that's interesting. It's not an segmentation fault at all.

It means that the CPU can't properly access VRAM. Please provide full dmesg output.
Comment 8 Marco Trevisan (Treviño) 2014-05-05 15:51:44 UTC
Created attachment 98499 [details]
dmesg

(In reply to comment #7)
> (In reply to comment #6)
> > [0x7f4358c28e98] avcodec decoder: Using VA API version 0.35 for hardware
> > decoding.
> > Bus Error (core dumped)
> 
> Oh! Well that's interesting. It's not an segmentation fault at all.
> 
> It means that the CPU can't properly access VRAM. Please provide full dmesg
> output.

Here you are...
Nothing seems directly related to this, though.
Comment 9 Christian König 2014-05-05 16:11:05 UTC
That's the problem:

[    1.714537] [drm] Detected VRAM RAM=1024M, BAR=128M

Your PCI BAR is smaller than usually, for a REDWOOD 256M are normal. Going to hack up a patch for this.
Comment 10 Marco Trevisan (Treviño) 2014-05-05 16:18:39 UTC
(In reply to comment #9)
> That's the problem:
> 
> [    1.714537] [drm] Detected VRAM RAM=1024M, BAR=128M
> 
> Your PCI BAR is smaller than usually, for a REDWOOD 256M are normal. Going
> to hack up a patch for this.

Nice to hear!
But in these cases where there's not enough memory, shouldn't the vdpau driver to fail returning an error (making the client to fallback to software rendering), instead of crashing?
Comment 11 Christian König 2014-05-05 16:22:44 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > That's the problem:
> > 
> > [    1.714537] [drm] Detected VRAM RAM=1024M, BAR=128M
> > 
> > Your PCI BAR is smaller than usually, for a REDWOOD 256M are normal. Going
> > to hack up a patch for this.
> 
> Nice to hear!
> But in these cases where there's not enough memory, shouldn't the vdpau
> driver to fail returning an error (making the client to fallback to software
> rendering), instead of crashing?

It's not the VDPAU driver that's failing here, it's the kernel.

When the kernel can't place a buffer into visible VRAM the buffer should be moved into GART instead for CPU access. But instead we just return a SIGBUS to the application effectively crashing it.
Comment 12 Christian König 2014-05-05 16:45:47 UTC
Created attachment 98501 [details] [review]
Possible fix.

Please try the attached kernel patch.

Only tested with 3.15-rc2, but should apply to 3.14 as well.
Comment 13 Marco Trevisan (Treviño) 2014-05-06 15:53:53 UTC
(In reply to comment #12)
> Created attachment 98501 [details] [review] [review]
> Possible fix.
> 
> Please try the attached kernel patch.
> 
> Only tested with 3.15-rc2, but should apply to 3.14 as well.

Thanks, it applies to 3.13 as well, but still same issue :(

Exactly same crash (http://paste.ubuntu.com/7405255/) and dmesg (http://paste.ubuntu.com/7405259/)
Comment 14 Christian König 2014-05-06 16:10:40 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > Created attachment 98501 [details] [review] [review] [review]
> > Possible fix.
> > 
> > Please try the attached kernel patch.
> > 
> > Only tested with 3.15-rc2, but should apply to 3.14 as well.
> 
> Thanks, it applies to 3.13 as well, but still same issue :(
> 
> Exactly same crash (http://paste.ubuntu.com/7405255/) and dmesg
> (http://paste.ubuntu.com/7405259/)

Mhm, your dmesg looks like you are still booting the standard Ubuntu kernel:
[    0.000000] Linux version 3.13.0-24-generic (buildd@batsu) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 (Ubuntu 3.13.0-24.47-generic 3.13.9)

Grub usually selects the kernel with the highest version number for boot. Please double check that you selected the self compiled version in grub while booting.
Comment 15 Marco Trevisan (Treviño) 2014-05-06 16:23:48 UTC
(In reply to comment #14)
> Mhm, your dmesg looks like you are still booting the standard Ubuntu kernel:
> [    0.000000] Linux version 3.13.0-24-generic (buildd@batsu) (gcc version
> 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
> (Ubuntu 3.13.0-24.47-generic 3.13.9)
> 
> Grub usually selects the kernel with the highest version number for boot.
> Please double check that you selected the self compiled version in grub
> while booting.

Sorry, that wasn't the problem since I patched the ubuntu kernel itself, but I did forgot to update the initramfs, thus it was still loading the old module -_-.

Anyway, once I fixed it this works like a charm!
Thanks a lot (and sorry again for the trouble)!
Comment 16 Christian König 2014-05-06 16:35:30 UTC
Thanks for for the help.
Comment 17 Marco Trevisan (Treviño) 2014-05-07 16:13:55 UTC
(In reply to comment #16)
> Thanks for for the help.

Thank you!

Once the patch gets into a drm branch, could you also please forward this to stable? As it would be very nice to get this included by distros as stable update.

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.