[regression] 2.6.37-post-rc7 with radeon kms: reproducably locks up hard when using desktop cube of kwin
I will add a regression entry in bugzilla after I got the URL of that mail.
Hi!
No, I do not actively search for lockup bugs, but they seem to search me ;).
martin@shambhala:~> cat /proc/version Linux version 2.6.38-rc7-tp42-00142-g212e349 (martin@shambhala) (gcc version 4.4.5 (Debian 4.4.5-11) ) #4 PREEMPT Sat Mar 5 12:03:41 CET 2011
locks up hard when using desktop cube of kwin from KDE 4.5.1.
It happens within a few seconds to about 30 seconds after activating the effect with Ctrl-F11. Otherwise the machine seems to work fine so far - if that continues I do not have much of a problem with the bug since I do not use desktop cube other than for getting a feel of compositing performance. Effects seem to be more fluent, more smooth anyway, I guess due to Radeon KMS page flipping.
I am using X.org 1.9.4 with Radeon driver 1:6.14.0-1 on Debian Wheezy/Sid/Experimental on a ThinkPad T42 with:
martin@shambhala:~> lspci -nn | grep VGA 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50]
This didn't happen with 2.6.37-tp42-rtime-00004-g9eb63ce, same gcc.
Possibly related to bug #28622 "radeon video lookup".
As I am in my holidays in Sevilla I will only care about bisecting when it rains three days in a row ;) - cause I insist on my holidays being holidays and so will only do light kernel testing ;). I wanted to report this nonetheless since at least on my machine this is really easy to reproduce.
Ciao,
Am Saturday 05 March 2011 schrieb Martin Steigerwald:
As it reads here, this is about 2.6.38, not 2.6.37. Changed subject.
Am Saturday 05 March 2011 schrieb Martin Steigerwald:
[...]
Reported as
Bug 30472 - 2.6.38-post-rc7 with radeon kms: reproducably locks up hard when using desktop cube of kwin
Thanks,
Am Saturday 05 March 2011 schrieb Martin Steigerwald:
[...]
Upto now I did not experience a lockup except for above situation.
I darkly remember that someone told me in another thread on how to reduce commits to bisect to radeon drm kms stuff. That might be a viable alternative. Ah, it was Ted in "stable? quality assurance" (Message-Id: 20100907025110.GD6134@thunk.org)
git bisect start 2.6.34 2.6.33 -- drivers/gpu/drm/radeon
Hmmm, I might try this.
But not today, its sunny here ;).
Ciao,
On Sat, Mar 5, 2011 at 9:10 AM, Martin Steigerwald Martin@lichtvoll.de wrote:
Did you also update your ddx or mesa during this period? It might also be a issue in the userspace acceleration drivers. Are you using the r300 classic or r300 gallium 3D driver?
Alex
Am Sunday 06 March 2011 schrieb Alex Deucher:
On Sat, Mar 5, 2011 at 9:10 AM, Martin Steigerwald Martin@lichtvoll.de
wrote:
Debian maintainers activated the gallium one in the meantime:
martin@shambhala:~> glxinfo | grep OpenGL OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV350 OpenGL version string: 2.1 Mesa 7.10 OpenGL shading language version string: 1.20 OpenGL extensions:
I think I tried the desktop cube with the gallium one already, but I am not absolutely sure.
I have a 2.6.37 kernel still at hand and will test with just changing the kernel.
Thanks,
Am Sunday 06 March 2011 schrieb Martin Steigerwald:
I verified this. Lockup happens with 2.6.38, last one tested rc8-gfb62c00, but not with 2.6.37 with exactly same userspace. Needed to try the effect several times, as this time the lockup with 2.6.38 only happened shortly after the second activation of the effect.
Thanks,
Its rainy again in Sevilla...
Am Sunday 06 March 2011 schrieb Dave Airlie:
Attached. I have dmesgs available as well. Both kernels are mainly upstream. The 2.6.37 contains some recursive mtime patches from Jan for Ext3/4 that are very likely unrelated. For 2.6.38 I am testing too hibernation patches from Raphael, but the lockup also happened with a plain vanilla 2.6.38 one before.
I'm guessing its either pageflipping or a later kernel allowing some feature of mesa to be used.
I guess so too. This is the mesa stuff I use:
martin@shambhala:~> apt-show-versions | egrep "(libdrm|libkms|libgl1- mesa)" libdrm-intel1/sid uptodate 2.4.23-3 libdrm-nouveau1/wheezy uptodate 2.4.21-1~squeeze3 libdrm-radeon1/sid uptodate 2.4.23-3 libdrm-radeon1-dbg/sid uptodate 2.4.23-3 libdrm2/sid uptodate 2.4.23-3 libdrm2-dbg/sid uptodate 2.4.23-3 libgl1-mesa-dev/sid uptodate 7.10-4 libgl1-mesa-dri/sid uptodate 7.10-4 libgl1-mesa-dri-dbg/sid uptodate 7.10-4 libgl1-mesa-glx/sid uptodate 7.10-4 libgl1-mesa-glx-dbg/sid uptodate 7.10-4 libkms1/sid uptodate 2.4.23-3
Thanks,
On Tue, Mar 8, 2011 at 7:35 PM, Martin Steigerwald Martin@lichtvoll.de wrote:
Okay can you try using an xorg.conf with Option "pageflip" "false" set in it for the radeon.
Dave.
On Die, 2011-03-08 at 19:40 +1000, Dave Airlie wrote:
That should be
Option "EnablePageFlip" "false"
Am Tuesday 08 March 2011 schrieb Michel Dänzer:
On Die, 2011-03-08 at 19:40 +1000, Dave Airlie wrote:
On Tue, Mar 8, 2011 at 7:35 PM, Martin Steigerwald
Martin@lichtvoll.de wrote:
So the desktop cube runs absolutely stable with 2.6.38 when I disable page flipping. The hang just happens with enabled page flipping. But beside the desktop cube I had no other hang with page flipping enabled.
If its not related to exact gfx chip, it should be easily reproducable:
- install kwin
- kwin --replace your current window manager
- make sure composoting is enabled if it isn't
- Ctrl-Alt-F11, maybe hang happens on the second time, not on the first, but hang should happen quite reproducably
My compositing settings are:
martin@shambhala:~> grep -A 13 "[Compositing]" ~/.kde/share/config/kwinrc [Compositing] AnimationSpeed=3 Backend=OpenGL CheckIsSafe=true DisableChecks=true Enabled=true GLDirect=true GLMode=TFP GLTextureFilter=2 GLVSync=true HiddenPreviews=5 OpenGLIsUnsafe=false XRenderSmoothScale=false
(I disabled checks whether compositing is performant or safe enough sometime ago, as KWin did not enable compositing otherwise, maybe due to performance reasons. But from what I know OpenGL compositing should be pretty safe on my chipset.)
Thanks,
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Dave Airlie -
Martin Steigerwald -
Michel Dänzer