[Bug 77394] New: Desktop freezes often when KDE starts compositing or mplayer GL window changes
https://bugs.freedesktop.org/show_bug.cgi?id=77394
Priority: medium Bug ID: 77394 Assignee: dri-devel@lists.freedesktop.org Summary: Desktop freezes often when KDE starts compositing or mplayer GL window changes Severity: major Classification: Unclassified OS: Linux (All) Reporter: nine@detonation.org Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI
When I turn on KDE compositing the desktop freezes more often than not. These freezes can also be provoked when configuring mplayer for GL output and opening a video file. If that alone is not enough, just change repeatedly from window to fullscreen and back. Attaching Xorg.0.log and dmesg of such a crash.
I can reboot the system cleanly using alt+sysrq+r and ctrl+alt+del but any attempts to get a nice backtrace of the X server with gdb failed due to the process hanging in kernel space.
Hardware: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT [Radeon R9 270X]
Running: kernel 3.14, libdrm2-2.4.99~git20140411-1.1, xorg-x11-server-7.6_1.15.99.902-306.1 Mesa-10.2~git20140411-5.1 llvm-r600-3.5~svn20140408-1.1.x86_64 openSUSE 13.1
Downgrading components to openSUSE 13.1 stock versions did not help except for downgrading the kernel to 3.11.
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #1 from nine@detonation.org --- Created attachment 97304 --> https://bugs.freedesktop.org/attachment.cgi?id=97304&action=edit dmesg taken after desktop freeze
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #2 from nine@detonation.org --- Created attachment 97305 --> https://bugs.freedesktop.org/attachment.cgi?id=97305&action=edit Xorg.0.log of a session after a freeze
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #3 from Alex Deucher agd5f@yahoo.com --- Does this patch set help: http://lists.freedesktop.org/archives/dri-devel/2014-April/057512.html and the new *mc2.bin ucode here: http://people.freedesktop.org/~agd5f/radeon_ucode/
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #4 from nine@detonation.org --- (In reply to comment #3)
Does this patch set help: http://lists.freedesktop.org/archives/dri-devel/2014-April/057512.html
Which tree does this apply to?
I applied it to 3.14 but the third patch was rejected and the resulting kernel crashed on any attempt to open a GL window.
On Linus' master the third patch was rejected as well but at least I was able to enable desktop effects and start mplayer. Still got problems with the screen suddenly going blank and the system freezing (had those before as well but much less frequently, maybe due to lower GL usage).
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #5 from Alex Deucher agd5f@yahoo.com --- It might be easier to just test Christian's fixes branch here: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
Does disabling dpm help? Append radeon.dpm=0 to the kernel command line in grub. If that helps, the patches I mentioned may help.
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #6 from nine@detonation.org --- With the drm-fixes-3.15-wip branch, updated firmware and radeon.dpm=0 I can now run KDE with desktop effects enabled and mplayer's GL output seems stable. But I can still provoke kernel panics (hard lockup on CPU x) quite easily by pressing and holding 'f' in mplayer quickly and repeatedly going into fullscreen mode and back to windowed mode. I also get those blank screens and lockups on resume from disk.
I guess there are multiple issues here working together to spoil my user experience ;)
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #7 from nine@detonation.org --- I can easily reproduce GPU lockups by switching the power profile to high. I bought a new power supply that has power to spare, but it did not change anything.
Should I file a separate bug report for these lockups?
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #8 from nine@detonation.org --- Created attachment 97776 --> https://bugs.freedesktop.org/attachment.cgi?id=97776&action=edit dmesg after GPU lockup on setting power profile to high
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #9 from Alex Deucher agd5f@yahoo.com --- Do you still get lockups without forcing the power level to high? You shouldn't need to force it. On auto the hw will automatically switch between levels based on load.
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #10 from nine@detonation.org --- (In reply to comment #9)
Do you still get lockups without forcing the power level to high?
Normal desktop use seems stable as long as I don't use mplayer.
You shouldn't need to force it. On auto the hw will automatically switch between levels based on load.
I thought automatic switching is what dpm is about? Anyway setting power_profile to auto gave me an immediate lockup just like the high profile.
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #11 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #10)
(In reply to comment #9)
Do you still get lockups without forcing the power level to high?
Normal desktop use seems stable as long as I don't use mplayer.
You shouldn't need to force it. On auto the hw will automatically switch between levels based on load.
I thought automatic switching is what dpm is about? Anyway setting power_profile to auto gave me an immediate lockup just like the high profile.
Correct. Auto is the default power profile. So it appears that changing the state causes a problem.
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #12 from nine@detonation.org --- Today I gave in and installed fglrx. Despite considerable torture the system is stable, so I can at least rule out some hardware problem.
Do you have any suggestions on what I can do to help fix this problem? Considering that I have a way to reliably reproduce these GPU lockups, that I have the kernel source to play with and that I can ssh into the system, I may be able to gather more information. Unless the problem is likely to be in the firmware.
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #13 from nine@detonation.org --- After two months with a stable system using fglrx, I gave radeon a try again. I can still easily reproduce the GPU lockups using kernel 3.16.0-rc2-5.g19015a0-desktop and radeon_ucode fetched today. dmesg output changed a litte. Maybe this helps?
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #14 from nine@detonation.org --- Created attachment 102331 --> https://bugs.freedesktop.org/attachment.cgi?id=102331&action=edit dmesg after echo auto > power_profile
Problem starts at 131.600354
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #15 from nine@detonation.org --- News: I actually can switch power levels as much as I like as long as X was not started yet. Starting X afterwards gives me a stable system with changed power level. As soon as it was started once however, the lockups happen on trying to change the power level. Even if I shut down the X server.
Downgrading xorg-x11-server from 7.6_1.16.99.9-2.2 to 7.6_1.16.1-350.4 fixes this problem but then I get random lockups and crashes which is not much better :/
https://bugs.freedesktop.org/show_bug.cgi?id=77394
nine@detonation.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Desktop freezes often when |Radeon R9 270X GPU lockup |KDE starts compositing or |on power profile change |mplayer GL window changes |
https://bugs.freedesktop.org/show_bug.cgi?id=77394
--- Comment #16 from nine@detonation.org --- Today I finally made decent progress on this issue. I can confirm that the GPU lockups are not the X server's fault, since they appear also when using weston and indeed, when running the eglkms Mesa demo on the pure framebuffer.
Trying to find the exact OpenGL call that causes the lockup, I discovered, that when I change the power profile before starting any GL program (Mesa demo or display server), it continues to work until the next reboot. So all that was needed was a echo low > /sys/class/drm/card0/device/power_profile executed before starting the X server and I could change power profile at runtime.
I then turned on dpm again and indeed: echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level called by an ExecStartPre script from the display-server service file fixes the issue completely for me and I have now a fully working dpm :)
So it seems like the first change of performance level/profile initializes something that must be initialized before the first GL call or CRTC change for power management to be stable. Any idea what this something might be?
https://bugs.freedesktop.org/show_bug.cgi?id=77394
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED
--- Comment #17 from Martin Peres martin.peres@free.fr --- -- 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/488.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org