Kernel - Linux 3.11rc4 Version mesa-common-dev - 9.2.0~git20130729+9.2.9b8ad643-0ubuntu0sarvatt~raring Version libg3dvl-mesa - 9.3~git1308091520.e8d897~gd~r Driver - Gallium 0.4 To repeat the freezing - start the video on player with support for VDPAU (mplayer or XBMC), stop it, and then run another video.
My graphic card - Mobility Radeon HD 4650
Created attachment 83941 [details] dmesg log
Please post the full dmesg output, especially the bootup sequence. Does that also happen with dpm disabled?
Created attachment 83946 [details] Full dmesg log
(In reply to comment #3) > Does that also happen with dpm disabled? Without "radeon.dpm=1", all played normally
Also on kernel 3.11rc5
Created attachment 84347 [details] dmesg log
Look alike bug here: screen goes black and freeze for a while when playing the second video using VDPAU with mplayer. Upon "screen return", the whole display is corrupted and unusable, requiring reboot. Arch Linux testing packages except for the kernel which is custom build. Card: Radeon Mobility 4650 HD Linux kernel: 3.11rc6 (commit: b36f4be, it's called -dirty in the dmesg log but I don't know why, will try to figure that out) Mesa: 9.2.0rc1 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0-rc1 OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 9.2.0-rc1 OpenGL shading language version string: 1.30
You might try this patch: http://people.freedesktop.org/~agd5f/0001-drm-radeon-atombios-fix-variable-sized-arrays-for.patch
Created attachment 84354 [details] New dmesg log with patched kernel This is the new dmesg log. I tried the patch but the bug is still here in my case. However the "Bad LCD record" error is different now and some lines in the end are not in the new log.
Created attachment 84362 [details] X server logs Note: if I quickly kill the second mplayer right after the start of the video I can avoid the crash, but UVD won't work anymore and mplayer will permanently end with some errors (if VDPAU is forced): Selected video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (VDPAU acceleration) [libavcodec] Selected audio codec: ATSC A/52A (AC-3) [libavcodec] AUDIO: 48000 Hz, 2 ch, floatle, 384.0 kbit/12.50% (ratio: 48000->384000) AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... VIDEO: 1280x720 23.976 fps 0.0 kbps ( 0.0 kB/s) VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration [ vdpau] Failed creating VDPAU decoder: An invalid/unsupported VdpDecoderProfile value was supplied. FATAL: Cannot initialize video driver. VIDEO: 1280x720 23.976 fps 0.0 kbps ( 0.0 kB/s) VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration [ vdpau] Failed creating VDPAU decoder: An invalid/unsupported VdpDecoderProfile value was supplied. FATAL: Cannot initialize video driver. [h264_vdpau @ 0x7f736c111cc0]decode_slice_header error [h264_vdpau @ 0x7f736c111cc0]no frame! Error while decoding frame! FATAL: Could not initialize video filters (-vf) or video output (-vo). But right after that my X session was killed and the X server kept exiting with bus errors when starting new ones (see attached log).
Is this still an issue with this kernel patch? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=858a41c853cef2cb01de34dae334c19c1c15b237
My laptop is dead, I can not test this anymore.
Same problem here, resurrecting the bug. The situation is better with the "Disable semaphores for UVDv1" patch from bug #85320, but still not completely working. Tested with: mplayer -vo vdpau -vc ffh264vdpau movie.mkv It is an older machine (but still serving well): CPU: 32bit Intel P4 MB: MS-6728, Intel 865PE; Notably no MSIs! GPU: RV730 [Radeon HD 4600 AGP Series]; The "abomination" on AGP! distro: gentoo gcc: 4.9.2 xorg: 1.17.1 mesa: 10.5.2 (r600, llvm enabled) xf886-video-ati: 7.5.0 mplayer: 1.2_pre20150214 ffmpeg: 2.6.2 1) Stable kernel 4.0.2 - Movie plays for a few seconds, then the whole desktop freezes. - Keyboard dead, display dead. Ctrl+F1 to switch to console not possible. - Immediate poweroff (ACPI button) makes a clean shutdown. After few seconds not possible, only hard reboot. - Relevant line of dmesg: radeon 0000:01:00.0: failed to get a new IB (-35) 2) Stable kernel 4.0.2 + patch "Disable semaphores ..." - Movie plays for a longer time (10's of second) well. - Then the video stucks in a short loop (~second), while audio, subtitles and rest of the destop still ok. - After longer time (~minutes) audio and the whole desktop freezes. - But I can do Ctrl+F1 to switch to console and even restart X, but the image is corrupted. - Relevant line of dmesg: radeon 0000:01:00.0: failed to sync rings (-35) 3) Kernel 4.1.0-rc2 + ~airlied/drm-fixes (commit 3790e39) - At first, almost the same as in 2), maybe the times are even longer. - But in the end, the whole system freezes, no Ctrl+F1, no clean poweroff. - I have no dmesg saved (at the moment) due to the fatal crash.
Created attachment 115638 [details] dmesg Linux 4.0.2 (1)
Created attachment 115640 [details] dmesg Linux 4.0.2 + "Disable semaphores ..." patch
Created attachment 115641 [details] dmesg Linux 4.0.2 + patch "Disable semapthores..." #2 Another try with the patched kernel. This time I quit mplayer while stil playing ok a run again. Maybe contains useful info.
Eh, now I realized that this bug is also about DPM. In my case "radeon.dpm=0" does not help. Sorry for that, I should have filed a new bug. Also, after more testing it seems that 4.1.0-rc-2 + drm-fixes behaves more like 4.0.2 + patch. It depends, sometimes Ctrl+F1 / restart X / clean poweroff is possible, sometimes not.
-- 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/drm/amd/issues/368.
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.