kernel from '~airlied/linux/log/?h=drm-next', mesa-git 20130706, xf86-video-radeon-git 20130706, X server 1.14.2, Archlinux X86_64
X seems quite stable when not playing videos. However while playing videos(without UVD), after few minutes, X will be not responding.
Tested with kernel 3.9.9, there is no such problem. Problem only existed with kernel 3.10+. Maybe there is some issue with the latest UVD patches. (UVD acturely works, and it was nice)
My hardware: Acer v3 551G, AMD A8 4500M, HD7640G+HD7670M, 4G+4G RAM
Created attachment 82234 [details]
only this one time I can switch to tty2 to get these logs. X seems not break but still not responding.
What API(s) (Xv, XvMC, VDPAU, etc.) and mplayers (mplayer, flash, vlc, xbmc, etc.) are you using to play the videos?
Thanks for reply, I tried mplayer and snappy-player(gstreamer1.0 based), all have such problem.
I didn't use -vo to specific video output, but Archlinux mplayer build with vdpau support, so i guess by default mplayer will use vdpau.
It's not easy to get logs (cause X freeze), so if there any thing I can do to assist, please let me know, this is really annoy.
BTW: The new power managment work like a charm, I love it.
Created attachment 82240 [details]
systemd log(include dmesg)
"mplayer -vo vx" still freeze system after minutes playing. It happended quite randomly, sometimes it took long time, sometimes it took short time.
I am not sure if this issue cuased by playing video any more. I have tried "mplayer -vo x11", problem existed. And I also tried not playing any videos, but couples of hours later i still got X freeze once(May caused by other problem).
But playing videos will reproduce this for sure.
(In reply to comment #3)
> I didn't use -vo to specific video output, but Archlinux mplayer build with
> vdpau support, so i guess by default mplayer will use vdpau.
I wouldn't expect so, but you can easily verify it in mplayer's terminal output.
> BTW: The new power managment work like a charm, I love it.
Does the problem occur without DPM?
(In reply to comment #7)
> (In reply to comment #3)
> > I didn't use -vo to specific video output, but Archlinux mplayer build with
> > vdpau support, so i guess by default mplayer will use vdpau.
> I wouldn't expect so, but you can easily verify it in mplayer's terminal
> > BTW: The new power managment work like a charm, I love it.
> Does the problem occur without DPM?
Yes, with or without DPM makes no difference. I fallback to Arch offical kernel 3.10, mesa 9.1.4, xf86-video-ati 7.10, tried play videos with mplayer(default output is vdpau, but no UVD hardware acceleration), and minutes later I got black screen this time.
PS: I didn't have xorg.conf, all radeon settings were default.
latest kernel from ~airlied/linux/log/?h=drm-next, there is no more error in dmesg. But system still freeze randomly.
linux 3.11-rc4, mesa git 20130805, xf86-video-ati 7.2.0, system freeze and not response at all (even the magic sysrq) after about one hour.
playing video or not make no different. I tested, when using chromium open a page and leave it there, system still freeze. And if screen goes black, it happens, too.
Are you running the same userspace stack with both kernel 3.9 and kernel 3.10/3.11? If so, it sounds like this is UVD related.
(In reply to comment #11)
> Are you running the same userspace stack with both kernel 3.9 and kernel
> 3.10/3.11? If so, it sounds like this is UVD related.
Yes, I have two kernels: arch official kernel 3.9.9 and kernel 3.11-rc4(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git) which compiled myself.
3.9.9 was quiet stable here.
problem still exist in kernel 3.11-rc7 git. Is there any way to disable UVD support?
problem still exist in kernel git 20130918
linux 3.11.2 without radeon dpm, seems stable now. But still have randomly freeze problem with dpm on.
-- 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/448.