[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152
Bug ID: 88152 Summary: 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: arthur.marsh@internode.on.net
Created attachment 111903 --> https://bugs.freedesktop.org/attachment.cgi?id=111903&action=edit dmesg output
Running Debian unstable x86/64 on AMD64 (4 cores) using a Radeon 3850HD graphics card with Linus git head kernel.
H.264 videos at 720p or 1080p resolution cause lock-up with VLC (but not with mpv --vo vdpau).
Using: mesa-vdpau-drivers:amd64 10.3.2-1 libdrm-radeon1:amd64 2.4.58-2 xserver-xorg-video-radeon 1:7.5.0-1 vlc 2.2.0~rc2-1
I don't have any short non-commercial videos to demonstrate the problem, but it does appear more likely with encodes from broadcast sources than blu-rays, suggesting that corrupt video gets fed through to where it causes a gpu lock-up while audio playback and other processes continue.
$ lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] RS780 Host Bridge 00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (ext gfx port 0) 00:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (PCIE port 2) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 3a) 00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge 00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV670 [Radeon HD 3690/3850] 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV670/680 HDMI Audio [Radeon HD 3690/3800 Series] 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
# vdpauinfo display: :0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0
Video surface:
name width height types ------------------------------------------- 420 8192 8192 NV12 YV12 422 8192 8192 UYVY YUYV 444 8192 8192 Y8U8V8A8 V8U8Y8A8
Decoder capabilities:
name level macbs width height ------------------------------------------- MPEG1 0 9216 2048 1152 MPEG2_SIMPLE 3 9216 2048 1152 MPEG2_MAIN 3 9216 2048 1152 H264_BASELINE 41 9216 2048 1152 H264_MAIN 41 9216 2048 1152 H264_HIGH 41 9216 2048 1152 VC1_ADVANCED 4 9216 2048 1152
Output surface:
name width height nat types ---------------------------------------------------- B8G8R8A8 8192 8192 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 R8G8B8A8 8192 8192 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 R10G10B10A2 8192 8192 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 B10G10R10A2 8192 8192 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
Bitmap surface:
name width height ------------------------------ B8G8R8A8 8192 8192 R8G8B8A8 8192 8192 R10G10B10A2 8192 8192 B10G10R10A2 8192 8192 A8 8192 8192
Video mixer:
feature name sup ------------------------------------ DEINTERLACE_TEMPORAL y DEINTERLACE_TEMPORAL_SPATIAL - INVERSE_TELECINE - NOISE_REDUCTION y SHARPNESS y LUMA_KEY - HIGH QUALITY SCALING - L1 - HIGH QUALITY SCALING - L2 - HIGH QUALITY SCALING - L3 - HIGH QUALITY SCALING - L4 - HIGH QUALITY SCALING - L5 - HIGH QUALITY SCALING - L6 - HIGH QUALITY SCALING - L7 - HIGH QUALITY SCALING - L8 - HIGH QUALITY SCALING - L9 -
parameter name sup min max ----------------------------------------------------- VIDEO_SURFACE_WIDTH y 48 2048 VIDEO_SURFACE_HEIGHT y 48 1152 CHROMA_TYPE y LAYERS y 0 4
attribute name sup min max ----------------------------------------------------- BACKGROUND_COLOR y CSC_MATRIX y NOISE_REDUCTION_LEVEL y 0.00 1.00 SHARPNESS_LEVEL y -1.00 1.00 LUMA_KEY_MIN_LUMA y LUMA_KEY_MAX_LUMA y
I am happy to supply additional information or try things to narrow down the source of the problem.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #1 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 111904 --> https://bugs.freedesktop.org/attachment.cgi?id=111904&action=edit dmesg output
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #2 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 111905 --> https://bugs.freedesktop.org/attachment.cgi?id=111905&action=edit 2015010719dmesg.txt
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #3 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 111906 --> https://bugs.freedesktop.org/attachment.cgi?id=111906&action=edit 20150107dmesg.txt
https://bugs.freedesktop.org/show_bug.cgi?id=88152
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|DRM/AMDgpu |Drivers/Gallium/r600 Version|XOrg git |unspecified Product|DRI |Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #4 from Arthur Marsh arthur.marsh@internode.on.net --- The commit:
https://github.com/torvalds/linux/commit/dd5a74f2f982193620cfa1ef609df1ee805...
appears to at least reduce the problem.
Is there any (semi-)automated way to check for any more occurences of signed variables that should be unsigned?
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #5 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112092 --> https://bugs.freedesktop.org/attachment.cgi?id=112092&action=edit 20150112dmesg.txt
After updating to the Linus git head kernel with https://github.com/torvalds/linux/commit/dd5a74f2f982193620cfa1ef609df1ee805... applied, and applying the patch at http://article.gmane.org/gmane.linux.kernel.mm/127052 I still had vlc lock-up with one video with 20150112dmesg.txt dump.
mediainfo reports the video format as:
Format : MPEG-4 Format profile : Base Media Codec ID : isom File size : 2.54 GiB Duration : 48mn 0s Overall bit rate : 7 579 Kbps Encoded date : UTC 2010-01-10 03:49:24 Tagged date : UTC 2010-01-10 03:49:24
Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.0 Format settings, CABAC : Yes Format settings, ReFrames : 3 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 48mn 0s Source duration : 47mn 59s Bit rate : 7 110 Kbps Width : 1 440 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 29.970 fps Standard : NTSC Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.153 Stream size : 2.38 GiB (94%) Source stream size : 2.49 GiB (98%) Language : English Encoded date : UTC 2010-01-10 03:49:24 Tagged date : UTC 2010-01-10 03:49:24 Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 mdhd_Duration : 2880936
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #6 from Christian König deathsimple@vodafone.de --- (In reply to Arthur Marsh from comment #4)
The commit:
https://github.com/torvalds/linux/commit/ dd5a74f2f982193620cfa1ef609df1ee805781d4
appears to at least reduce the problem.
The patch can't affect the issue, cause it only applies to non UMS mode which is completely deprecated and doesn't support UVD at all.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #7 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112109 --> https://bugs.freedesktop.org/attachment.cgi?id=112109&action=edit 2015011216dmesg.txt - dmesg output with 3.19.0-rc4+
problem further reduced but not eliminated.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #8 from Arthur Marsh arthur.marsh@internode.on.net --- previous 2015011216dmesg.txt was inadvertantly with 3.19.0-rc3+
When playing the same video under kernel 3.19.0-rc4+ it played for longer before locking up.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #9 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112129 --> https://bugs.freedesktop.org/attachment.cgi?id=112129&action=edit 20150113dmesg.txt - video run under kernel 3.19.0-rc4+
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #10 from Arthur Marsh arthur.marsh@internode.on.net --- When I ran vlc on the file with VLC_VERBOSE=3 I had no GPU lockup.
When I ran vlc on the file with VLC_VERBOSE=2 the GPU locked up again around the same time as the previous test with kernel 3.19.0-rc4+. Might that suggest a timing issue?
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #11 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112166 --> https://bugs.freedesktop.org/attachment.cgi?id=112166&action=edit vlcdebug2.log, output from running vlc with VLC_VERBOSE=2
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #12 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112167 --> https://bugs.freedesktop.org/attachment.cgi?id=112167&action=edit 2015011322dmesg.txt dmesg output with GPU lockup when VLC_VERBOSE=2
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #13 from Arthur Marsh arthur.marsh@internode.on.net --- Upgraded mesa-related packages to 10.4.2-1.
Still seeing a lockup a few minutes into video playback.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #14 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112175 --> https://bugs.freedesktop.org/attachment.cgi?id=112175&action=edit 2015011404dmesg.txt dmesg output with mesa 10.4.2
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #15 from Arthur Marsh arthur.marsh@internode.on.net --- Upgraded to current Linus git head and tried again.
This time there was no GPU reset associated with starting kdm (which had happened over the last few days), but the lock-up when playing the same video came less than 2 minutes into the video, much sooner than before.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #16 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112211 --> https://bugs.freedesktop.org/attachment.cgi?id=112211&action=edit 2015011421dmesg.txt - GPU lock-up less than 2 minutes into video play-back.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #17 from Arthur Marsh arthur.marsh@internode.on.net --- With kernel 3.19.0-rc5 the same video played right through with vlc without locking up.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #18 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112426 --> https://bugs.freedesktop.org/attachment.cgi?id=112426&action=edit 20150119dmesg.txt 3.19.0-rc5 dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #19 from Arthur Marsh arthur.marsh@internode.on.net --- A further run of the same video with kernel 3.19.0-rc5, doing some skipping of the the video.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #20 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112447 --> https://bugs.freedesktop.org/attachment.cgi?id=112447&action=edit 2015011907dmesg.txt - lockup with vlc and 3.19.0-rc5
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #21 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112458 --> https://bugs.freedesktop.org/attachment.cgi?id=112458&action=edit 2015011922dmesg.txt - lockup with 3.19.0-rc5 and 848x480 resolution video
First lock-up with lower than 720p resolution video playback
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #22 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112606 --> https://bugs.freedesktop.org/attachment.cgi?id=112606&action=edit 20150122dmesg.txt lock-up with same video after radeon updates to 3.19.0-rc5
Rebuilt the kernel after the latest Radeon updates to Linus' 3.19.0-rc5, lock-up occurred sooner.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #23 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112660 --> https://bugs.freedesktop.org/attachment.cgi?id=112660&action=edit 2015012222dmesg.txt test after upgrading vlc.
I upgraded vlc to 2.2.0~rc2-2 and re-tested against the same video running under the current Linus' git head kernel.
There was a gpu lock-up again - each different test seems to have the lock-up happen at a different stage in play-back, as if there is a non-deterministic event leading to the lock-up.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #24 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112868 --> https://bugs.freedesktop.org/attachment.cgi?id=112868&action=edit 20150127dmesg.txt with 3.19.0-rc6 - lock-up after a few seconds of video play
with kernel 3.19.0-rc6, the gpu locked up after a few seconds of playing the same video.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #25 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112889 --> https://bugs.freedesktop.org/attachment.cgi?id=112889&action=edit 2015012718dmesg.txt lock-up with first post 3.19.0-rc6 patches applied
The lock-up occurred within the first 20 seconds of playing the video, but slightly later than with plain 3.19.0-rc6.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #26 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112901 --> https://bugs.freedesktop.org/attachment.cgi?id=112901&action=edit 2015012814dmesg.txt - lockup after updating kernel to latest radeon patches
With the latest radeon patches in the 3.19.0-rc6+ kernel, I still experienced a lockup.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #27 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 112955 --> https://bugs.freedesktop.org/attachment.cgi?id=112955&action=edit 20150130dmesg.txt - lock-up with the latest git head patches
vlc behaved differently - going green and stalling before finally causing a gpu lock-up.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #28 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 113239 --> https://bugs.freedesktop.org/attachment.cgi?id=113239&action=edit 20150207dmesg.txt - lock-up about 5 and a half minutes into video playback
After latest radeon and mm updates to Linus git head, the same video played back fine until about 5 and a half minutes into playback, then locked-up all video.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #29 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 113270 --> https://bugs.freedesktop.org/attachment.cgi?id=113270&action=edit 20150209dmesg.txt didn't lock up on usual video but did on another with 3.19 kernel
With the 3.19 kernel, I didn't get a lock-up with the usual test video but did eventually with another video.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #30 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 113394 --> https://bugs.freedesktop.org/attachment.cgi?id=113394&action=edit 2015021218dmesg.txt - lockup of screen except for mouse, was able to restart kdm
For the first time when I experienced a lock-up due to running vlc with vdpau, although the desktop was locked up apart from the mouse cursor, I was able to control-alt-F1 and restart kdm successfully.
Using current Linus' git head.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #31 from Arthur Marsh arthur.marsh@internode.on.net --- after last lock-up, although I could restart kdm, vdpau didn't work until I'd powered off and restarted the machine (vdpau failed even after a kexec restart):
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory [vo/vdpau] Error when calling vdp_device_create_x11: 1 Error opening/initializing the selected video_out (-vo) device. Video: no video
Ironically I was getting that message, even though I've only had Radeon hardware in this machine.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #32 from Michel Dänzer michel@daenzer.net --- (In reply to Arthur Marsh from comment #31)
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory [vo/vdpau] Error when calling vdp_device_create_x11: 1 Error opening/initializing the selected video_out (-vo) device. Video: no video
Ironically I was getting that message, even though I've only had Radeon hardware in this machine.
I guess the Xorg radeon driver couldn't initialize hardware acceleration, so it didn't advertise the VDPAU driver name, and libvdpau fell back to its hardcoded default 'nvidia'.
As for the hangs, I suspect they just happen randomly regardless of kernel version. Attaching even more dmesg files just clutters up this report and makes it harder for anyone to make sense of it.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #33 from Arthur Marsh arthur.marsh@internode.on.net --- Where to from here? I'm happy to build kernels and other packages from source, test and bisect, but I'm not a C programmer.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #34 from Christian König deathsimple@vodafone.de --- (In reply to Arthur Marsh from comment #33)
Where to from here? I'm happy to build kernels and other packages from source, test and bisect, but I'm not a C programmer.
Unfortunately we don't really have time taking care of the older hardware generations. Getting the new generations working has usually priority.
I have a couple of ideas what could cause this, but you clearly need to hack into the code to figure out what it is.
Sorry that I can't help here much, Christian.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #35 from Arthur Marsh arthur.marsh@internode.on.net --- Created attachment 114333 --> https://bugs.freedesktop.org/attachment.cgi?id=114333&action=edit multiple lockup errors immediately after starting video 2015031613dmesg.txt
After upgrading the kernel to 4.0.0-rc4, and vdpau / libdrm: libvdpau1:amd64 0.9-1 libdrm-radeon1:amd64 2.4.59-1
I saw 4 GPU lockup error messages in dmesg (attached) within about half a second. The video itself locked up a very few seconds into playback. (I could supply the starting minute of the video if anyone was happy to look at it).
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #36 from Arthur Marsh arthur.marsh@internode.on.net --- With the first post- 4.0.0-rc7 drm update, I am no longer seeing the error, but have been unable to git-bisect to find the commit that fixed the problem.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #37 from Manuel Ullmann ullman.bugs@posteo.de --- Are you sure this bug is not related to bug #85320? Also, are you certain it is fixed in 4.0.0-rc7+ (linux git). In the mentioned report users of RV620/630 and RS780/880 (3450/2600 and 3200/4200 respectively) report GPU Resets and lockups when using vdpau hardware decoding. Do you use also mesa git and might the fix be rather introduced by a mesa git pull? That would explain, why you could not bisect it in linux git. I for my part have a Radeon HD 3200 Mobility (RS780M) and could still reproduce it with linux git. Did you test the fix thoroughly? For example I could start a video with hardware accelerated video decoding in mpv 40 times without a GPU Reset, but seeking in the video or disabling and reenabling the video track could cause it, while normal playback usually did not trigger it. Stable VLC however caused the GPU Reset on the first try using vaapi decoding with vdpau wrapper. It would be at least a good sign, if VLC can´t reproduce this anymore for you and maybe for the others at bug #85320 also.
So basically I´m asking, whether the described methods still cause a GPU Reset and what libraries you use in git version.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #38 from Arthur Marsh arthur.marsh@internode.on.net --- Sorry for the delay in replying, I tried a few more tests first.
The bad news is that even with a kernel build that didn't lock up on one complete playback of the video, even when trying skipping during the video, on a subsequent reboot and run I'd experience a lock-up.
The good news is that with current git head, even though I can experience lock-ups, I can restart kdm successfully following a lock-up. Prior to 4.0.0 kernel I needed to do a power down restart to undo the lock-up.
Besides Linus git head kernel built with current Debian experimental gcc-5, the other packages installed include:
libdrm - related packages at version 2.4.60-2 libvdpau1:amd64 0.9-1 mesa packages 10.4.2-2 xserver-xorg packages 1:7.5.0-1
At one stage I wanted to be sure that it wasn't a problem with the 3850HD video card so I removed it and used the onboard Radeon 3200HD and experienced the same problems.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #39 from Arthur Marsh arthur.marsh@internode.on.net --- Somehow, for the most part I'm no longer experiencing lock-ups.
Kernel is Linus' is current git head:
Linux version 4.1.0-rc2+ (root@am64) (gcc version 5.1.1 (Debian 5 .1.1-4) ) #1700 SMP PREEMPT Sat May 9 14:01:46 ACST 2015
DDX is 1:7.5.0-1+b1 libdrm is 2.4.60-3 mesa is 10.4.2-2 libc6 is 2.19-18
vlc is 2.2.1-1+b1
https://bugs.freedesktop.org/show_bug.cgi?id=88152
--- Comment #40 from Arthur Marsh arthur.marsh@internode.on.net --- The "disable semaphores" patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-4.1&id=013e...
appears to stop the lock-ups from happening.
It also appears to prevent one having multiple vdpau-enabled vlc sessions from working at the same time, and there are some issues with videos of different resolutions sometimes showing a black screen when their resolution is different from the previous video played. Playing a few different videos with vlc appears to reset things so that a video that previously showed a black screen plays fine again.
https://bugs.freedesktop.org/show_bug.cgi?id=88152
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE
--- Comment #41 from Christian König deathsimple@vodafone.de ---
*** This bug has been marked as a duplicate of bug 85320 ***
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org