Hardware: R7 360, Linux x86_64 Screen: 1680x1050 To reproduce this bug, play the "Weather" video at http://www.bbc.co.uk/weather using Firefox and Adobe's flash-plugin-11.2.202.643-release.x86_64. Ensure that "Hardware acceleration" is enabled, and then enter "Full screen" mode. On my PC, this results in a black screen with a small, blank rectangle in the top left corner. And then the flash plugin will crash a few minutes later. This does not happen with either i965 (Broadwell) or r600 (HD6450) hardware. Nor does it happen with Chromium and chromium-pepper-flash-23.0.0.162-1.fc24.x86_64 with my R7 360, although chromium-pepper-flash doesn't appear to use libvdpau_radeonsi.so either.
I think this bug is related to DRI3, because this change "fixes" the problem: diff --git a/src/gallium/state_trackers/vdpau/device.c b/src/gallium/state_trackers/vdpau/device.c index 81b7582..cd5afe2 100644 --- a/src/gallium/state_trackers/vdpau/device.c +++ b/src/gallium/state_trackers/vdpau/device.c @@ -64,7 +64,7 @@ vdp_imp_device_create_x11(Display *display, int screen, VdpDevice *device, pipe_reference_init(&dev->reference, 1); #if defined(HAVE_DRI3) - dev->vscreen = vl_dri3_screen_create(display, screen); + //dev->vscreen = vl_dri3_screen_create(display, screen); #endif if (!dev->vscreen) dev->vscreen = vl_dri2_screen_create(display, screen);
Broadwells work OK with DRI3, but I have now reproduced this problem with both radeonsi and r600g.
Reproducable on Kabini APU too. DRI3 issue yes, it works only in DRI2 session, but LIBGL_DRI3_DISABLE=1 does not help in this case.
But yeah newer does not have VDPAU support, neither this 24 beta it seems: http://labs.adobe.com/downloads/flashplayer.html In couple months 11.2.x seems will cease to be supported anymore, so this might be time fixable... well in case they did not decide to enable VDPAU again :)
(In reply to smoki from comment #4) > In couple months 11.2.x seems will cease to be supported anymore, so this > might be time fixable... well in case they did not decide to enable VDPAU > again :) I don't see your point here. AFAIK the Flash plugin knows nothing about either DRI2 or DRI3, and it works fine with DRI2. So why shouldn't it work with DRI3 too? Especially since Broadwell + DRI3 is unaffected. To my mind, the Flash plugin has probably revealed a bug in Gallium's DRI3 layer. In which case, hoping that Adobe will "shoot the messenger" soon is just silly.
That was pure information :), as i tried to reproduce it with that old affected one and newest which does not have an issue since it does not have decode... so no offense, bug is there.
(In reply to Chris Rankin from comment #1) > I think this bug is related to DRI3, because this change "fixes" the problem: > > diff --git a/src/gallium/state_trackers/vdpau/device.c > b/src/gallium/state_trackers/vdpau/device.c > index 81b7582..cd5afe2 100644 > --- a/src/gallium/state_trackers/vdpau/device.c > +++ b/src/gallium/state_trackers/vdpau/device.c > @@ -64,7 +64,7 @@ vdp_imp_device_create_x11(Display *display, int screen, > VdpDevice *device, > pipe_reference_init(&dev->reference, 1); > > #if defined(HAVE_DRI3) > - dev->vscreen = vl_dri3_screen_create(display, screen); > + //dev->vscreen = vl_dri3_screen_create(display, screen); > #endif > if (!dev->vscreen) > dev->vscreen = vl_dri2_screen_create(display, screen); This works on r600g - NI/Turks XT with Firefox 49.0.2 and Konqueror 4.14.8 (KDE 4.14.9) plus flash-player-11.2.202.643-2.115.1.x86_64, too.
(In reply to Chris Rankin from comment #5) > I don't see your point here. AFAIK the Flash plugin knows nothing about > either DRI2 or DRI3, and it works fine with DRI2... Does this still work for you with DRI2? Asking becuase DRI2 seems now affected also.
(In reply to smoki from comment #8) > Does this still work for you with DRI2? Asking becuase DRI2 seems now > affected also. I can't say, because Adobe has now "upgraded" its Flash plugin to v24 and removed the hardware-accelerated v11 plugin from the Yum repository :-|
(In reply to Chris Rankin from comment #9) > (In reply to smoki from comment #8) > > Does this still work for you with DRI2? Asking becuase DRI2 seems now > > affected also. > > I can't say, because Adobe has now "upgraded" its Flash plugin to v24 and > removed the hardware-accelerated v11 plugin from the Yum repository :-| Yeah it is not have decode accel anymore, but issue is still there... it actually does not need to be VDPAU used just that hardware accel enabled. Asking as i just tried it now and now happens with DRI2 too, basically flash whatever default with our driver crashing browser... one just need to wait enough :D Interesting is that it works fine with AMD proprietary driver, so it is our bug likely... mesa probably.
Can you get a backtrace of a crash with gdb?
(In reply to Michel Dänzer from comment #11) > Can you get a backtrace of a crash with gdb? Hello Michel, no backtrace of a crash, but I could attach gdb on running konqueror process. BBC weather side need JAVA. Hope this help, too. /opt/mesa> konqueror & [2] 10181 /opt/mesa> Vector smash protection is enabled. openjdk version "1.8.0_111" OpenJDK Runtime Environment (IcedTea 3.2.0) (suse-33.1-x86_64) OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode) konqueror(10181)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data!; job URL = KUrl("http://s.update.rubiconproject.com/2/873648/analytics.js?si=52926&di=www.bbc.com&ap=&ti=6cada3a9-2f5f-48b1-861f-31fc282cc43f&dt=8736481428691810142000") data size = 0 konqueror(10181)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data!; job URL = KUrl("http://ps.eyeota.net/match/bounce/?bid=i0r4o4v&uid=LAuIY6Hs") data size = 0 (gdb) bt full #0 0x00007faaa40fe2bd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007faa9f4a5402 in _xcb_conn_wait () at /usr/lib64/libxcb.so.1 #2 0x00007faa9f4a7209 in xcb_wait_for_special_event () at /usr/lib64/libxcb.so.1 #3 0x00007fa9e961e4a6 in dri3_wait_present_events (scrn=scrn@entry=0x2e2f090) at vl/vl_winsys_dri3.c:183 ev = <optimized out> #4 0x00007fa9e961f3bc in vl_dri3_screen_texture_from_drawable (vscreen=0x2e2f090, drawable=<optimized out>) at vl/vl_winsys_dri3.c:558 scrn = 0x2e2f090 buffer = <optimized out> #5 0x00007fa9e961b119 in vlVdpPresentationQueueDisplay (presentation_queue=<optimized out>, surface=5, clip_width=0, clip_height=0, earliest_presentation_time=0) at presentation.c:234 dump_window = 0 pq = 0x2f0ab60 surf = 0x4198340 pipe = 0x2ef3fe0 tex = <optimized out> surf_templ = {reference = {count = 0}, texture = 0x400000000, context = 0x100000000, format = PIPE_FORMAT_NONE, width = 0, height = 0, writable = 0, u = {tex = {level = 3, first_layer = 0, last_layer = 0}, buf = {first_element = 3, last_element = 0}}} surf_draw = <optimized out> src_rect = {x0 = 1, x1 = 16809983, y0 = 68781024, y1 = 0} dst_clip = {x0 = 68780956, x1 = 0, y0 = 68780992, y1 = 0} dirty_area = <optimized out> compositor = 0x2e2ef48 cstate = 0x2f0ab70 vscreen = 0x2e2f090 #6 0x00007faa2efc37f3 in () at /usr/lib64/browser-plugins/libflashplayer.so #7 0x00007faa2ed522e9 in () at /usr/lib64/browser-plugins/libflashplayer.so #8 0x00007faa2ed524ed in () at /usr/lib64/browser-plugins/libflashplayer.so #9 0x00007faa2ed4fc5c in () at /usr/lib64/browser-plugins/libflashplayer.so #10 0x00007faa2eca69a9 in () at /usr/lib64/browser-plugins/libflashplayer.so #11 0x00007faa2ec2c390 in () at /usr/lib64/browser-plugins/libflashplayer.so #12 0x00007faa2f1c472f in () at /usr/lib64/browser-plugins/libflashplayer.so #13 0x00007faa2f1c57ec in () at /usr/lib64/browser-plugins/libflashplayer.so #14 0x00007faa2f12b191 in () at /usr/lib64/browser-plugins/libflashplayer.so #15 0x000015aebcff63f6 in () #16 0x00000dd1873ddb78 in () #17 0x00000dd1873ddae0 in () #18 0x00001be706c23128 in () #19 0x00001be706c23061 in () #20 0x0000000000000000 in () (gdb) info registers all rax 0xfffffffffffffdfc -516 rbx 0x2f00bb0 49286064 rcx 0x7faaa40fe2bd 140370873672381 rdx 0xffffffff 4294967295 rsi 0x1 1 rdi 0x7fffb0fac080 140736162611328 rbp 0x29b7e60 0x29b7e60 rsp 0x7fffb0fac070 0x7fffb0fac070 r8 0x0 0 r9 0x94 148 r10 0x0 0 r11 0x293 659 r12 0x29b7e78 43744888 r13 0x0 0 r14 0x0 0 r15 0x7fffb0fac080 140736162611328 rip 0x7faaa40fe2bd 0x7faaa40fe2bd <poll+45> eflags 0x293 [ CF AF SF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 st0 -nan(0x0fe2b2b2b) (raw 0xffff00000000fe2b2b2b) st1 -nan(0x2c002b002b002b) (raw 0xffff002c002b002b002b) st2 -nan(0xd300d300d300d30) (raw 0xffff0d300d300d300d30) st3 -inf (raw 0xffff0000000000000000) st4 -nan(0x10000ff00ff00ff0) (raw 0xffff10000ff00ff00ff0) st5 -inf (raw 0xffff0000000000000000) st6 0 (raw 0x00000000000000000000) st7 0 (raw 0x00000000000000000000) fctrl 0x37f 895 fstat 0x20 32 ftag 0xffff 65535 fiseg 0x7faa 32682 fioff 0x29bf75ed 700413421 foseg 0x7fff 32767 fooff 0xb0fabb38 -1325745352 fop 0x55c 1372 xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x18, 0x0, 0x1, 0x0, 0x3, 0x43, 0xed, 0x8, 0x48, 0x76, 0x64, 0x2, 0xb1, 0x4, 0x0, 0x0}, v8_int16 = {0x18, 0x1, 0x4303, 0x8ed, 0x7648, 0x264, 0x4b1, 0x0}, v4_int32 = {0x10018, 0x8ed4303, 0x2647648, 0x4b1}, v2_int64 = {0x8ed430300010018, 0x4b102647648}, uint128 = 0x000004b10264764808ed430300010018} xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x77, 0x0, 0xe0, 0x5, 0x0, 0x0, 0x0, 0x0, 0xf6, 0x1, 0xc4, 0x2, 0xf6, 0x1, 0xc4, 0x2}, v8_int16 = {0x77, 0x5e0, 0x0, 0x0, 0x1f6, 0x2c4, 0x1f6, 0x2c4}, v4_int32 = {0x5e00077, 0x0, 0x2c401f6, 0x2c401f6}, v2_int64 = {0x5e00077, 0x2c401f602c401f6}, uint128 = 0x02c401f602c401f60000000005e00077} xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x10, 0x0, 0x1, 0x0, 0x1c, 0x0, 0xed, 0x8, 0xb1, 0x4, 0x0, 0x0, 0x72, 0x0, 0x0, 0x0}, v8_int16 = {0x10, 0x1, 0x1c, 0x8ed, 0x4b1, 0x0, 0x72, 0x0}, v4_int32 = {0x10010, 0x8ed001c, 0x4b1, 0x72}, v2_int64 = {0x8ed001c00010010, 0x72000004b1}, uint128 = 0x00000072000004b108ed001c00010010} xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm7 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm8 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm9 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm10 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm11 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm12 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm13 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm14 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm15 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} mxcsr 0x1fa7 [ IE DE ZE PE IM DM ZM OM UM PM ] After this I have SysRq running KDE desktop: [40631.027856] sysrq: SysRq : SAK [40631.027895] tty tty7: SAK: killed process 24471 (Xorg): by session [40631.028084] tty tty7: SAK: killed process 24471 (Xorg): by controlling tty [40631.028088] tty tty7: SAK: killed process 24472 (radeon_cs:0): by controlling tty [40631.028090] tty tty7: SAK: killed process 24475 (InputThread): by controlling tty
Still there. But patch works, even with latest DRI3 updates.
Any progress? Michel? DRI2 vs DRI3 Wouldn't it be nice to have this in 7.1?
Michel and Christian, can we have this patch in 17.1 (final)? I have to apply it by hand on every build. Any further logs/debug needed?
The patch just disables DRI3 for VDPAU, so it cannot be applied anywhere as is. It would have to be guarded by an environment variable.
(In reply to Michel Dänzer from comment #16) > The patch just disables DRI3 for VDPAU, so it cannot be applied anywhere as > is. It would have to be guarded by an environment variable. I only intended that patch as a "proof of concept" anyway, i.e. that the problem really was being caused by DRI3. I'd be mortified if it were actually *applied* to Mesa, even if it were "guarded by an environment variable".
Created attachment 131644 [details] vdpauinfo
Sorry, ignore the 'vdpau' attachment I just uploaded, this belongs to another bug (wrong browser tab!)
-- 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/mesa/mesa/issues/1239.
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.