Summary: | System freeze randomly with latest kernel 3.10 (also 3.11-rc4) | ||
---|---|---|---|
Product: | Mesa | Reporter: | lh <jarryson> |
Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED MOVED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | jarryson |
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
xorg log
systemd log(include dmesg) |
Description
lh
2013-07-09 13:28:20 UTC
Created attachment 82234 [details]
xorg log
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 > output. > > > > 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. |
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.