Created attachment 89477 [details] DMESG output showing hardware info and lockup. Playing back MPEG-2 compressed video causes a GPU lockup and reset. This happens about 9 times out of 10 upon start of playback - the other time playback starts fine. About 4 out of 5 times the reset is successful and playback begins a catchup phase before continuing normally - otherwise it results in a complete system freeze. If playback actually starts it continues fine. Using VDPAU assisted playback via XBMC. Using software only playback works fine every time. h264 playback seems unaffected.
Same GPU lockup with [AMD/ATI] Caicos [Radeon HD 6450] which has UVD3. Happens upon start of playback of mpeg-2 files, 90% chance of lockup. On some files it seems better, on other worse. Maybe some frame errors are causing this.
Created attachment 89653 [details] DMESG output
Getting the same problem with mpeg2 on my E350.
Created attachment 89679 [details] dmesg
I would like to report same issue, though mine is Radeon 4550. (UVD2.2) lockup on every attempt with vdpau enabled, these are high bitrate ota broadcast recordings played through xbmc cmyth plugin on ubuntu 13.10 I've attached dmesg, will try directly playing files when I get back, but imagine same result.
actually isn't a lockup of gpu, but crashes program(xbmc) out
Created attachment 89698 [details] radeon 4550 dmesg
You may have a look at bug 69775. It was reported as fixed by this patch: [PATCH] drm/radeon: fix typo in fetching mpll params http://lists.freedesktop.org/archives/dri-devel/2013-November/049425.html The patch has not been merged yet, but should be soon.
Thanks. I have tried that patch in a kernel build kindly supplied by fritsch (https://github.com/fritsch/linux/commits/master) but the issue still remains - no improvement. I also built Mesa and the 2D driver from master late yesterday - still locks. Please let me know if I can test anything else!
Also getting the same problem using fritch's build here https://github.com/fritsch/linux that has that patch, on ubuntu saucy with xbmc using vdpau. Card in this instance is a radeon HD 7750. The surviving dmesg.0 and syslog from that session doesn't show any information related to the crash. If anything it crashed the system more thoroughly and quickly than the mainline kernels, requiring a reset-button press to recover.
Created attachment 90478 [details] dmesg file showing GPU resets with mplayer on A8-5500 I have a A8-5500 with 7560D igp (Debian Testing 64 bit with Xfce 4.10) and mesa, drm, llvm, glamor and kernel from latest git with the agd5f drm-fixes-3.13 merged - playing a certain mpeg2 clip with xbmc sends the GPU into a reset loop (i managed to get to tty1 and do a killall -9 xbmc.bin, but i had to restart because the resets continued and tty7 gave no video signal at all. Playing the same clip with mplayer shows green garbled image and after 3 tries (started playback, let it run for a few seconds, stopped) it did reset the gpu too only i was able to killall -9 mplayer from tty1 and after that one more gpu reset happened then the x server recovered. I had some dvds laying around and those had no issues and downloaded other mpeg2 clips too and those too worked fine with vdpau decoding, but with this particular clip vdpau messed stuff up badly. I found a link for the clip here: https://github.com/xbmc/xbmc/pull/399 This is the direct download link, its a mpeg2 clip, around 20MB: http://www.mediafire.com/?4dvvwj5aw2esv49 Attached dmesg from the mplayer session.
(In reply to comment #11) > I had some dvds laying around and those had no issues and downloaded other > mpeg2 clips too and those too worked fine with vdpau decoding, but with this > particular clip vdpau messed stuff up badly. > > I found a link for the clip here: > https://github.com/xbmc/xbmc/pull/399 > > This is the direct download link, its a mpeg2 clip, around 20MB: > http://www.mediafire.com/?4dvvwj5aw2esv49 I think this file is exceptional and so it not working is probably unrelated to whatever issue others are seeing. It doesn't work because vdpau doesn't support field coded mpeg2. I guess because it is very rare - other than compliance streams this is the first one I've seen in the wild, and given it's mpeg2 in mkv with ac3 and the cartoon content is a mix of progressive and interlaced (maybe from telecine and frame rate converted) I don't know if it's an amateur creation or something "real".
> I think this file is exceptional and so it not working is probably unrelated > to whatever issue others are seeing. > > It doesn't work because vdpau doesn't support field coded mpeg2. I guess > because it is very rare - other than compliance streams this is the first > one I've seen in the wild, and given it's mpeg2 in mkv with ac3 and the > cartoon content is a mix of progressive and interlaced (maybe from telecine > and frame rate converted) I don't know if it's an amateur creation or > something "real". The problem here is that a movie playback can mess up your session because the driver cannot cope with an exception caused by a specific video format. This should not happen in any circumstances.
(In reply to comment #6) > actually isn't a lockup of gpu, but crashes program(xbmc) out Yea, XBMC crashes on me if I enable VDPAU - and my card (HD4890) doesn't have UVD so it's also crashing trying to use shaders for mpeg2 (which work with mplayer -vc ffmpeg12vdpau) I wonder if others having the UVD lockups can also provoke them using mplayer -vc ffmpeg12vdpau
(In reply to comment #13) > > I think this file is exceptional and so it not working is probably unrelated > > to whatever issue others are seeing. > > > > It doesn't work because vdpau doesn't support field coded mpeg2. I guess > > because it is very rare - other than compliance streams this is the first > > one I've seen in the wild, and given it's mpeg2 in mkv with ac3 and the > > cartoon content is a mix of progressive and interlaced (maybe from telecine > > and frame rate converted) I don't know if it's an amateur creation or > > something "real". > > The problem here is that a movie playback can mess up your session because > the driver cannot cope with an exception caused by a specific video format. > This should not happen in any circumstances. I agree with you - I wasn't saying it didn't need fixing WRT to GPU lockups, just trying to add some info. It may be that the lock will be fixed by making UVD more resilient, but the file still won't play properly because it's unsupported - at least you'll know why.
Interesting. I tried again and the system hang on the first frames with mplayer. The only thing i could do was to use the sysrq combination to restart. Then i recompiled mesa without llvm and i played it a few times in a row with both mplayer and xbmc and didnt crash. It was a green slideshow but didnt crash.
-- 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/469.
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.