Created attachment 24816 [details] Xserver log Since 2.6.33-rc4 up to rc6 I randomly have garbled kwin shadows, either blue or yellow frames around the window shadows. In kernels 2.6.32 and <=2.6.33-rc3 this was not observable (=regression). Also described here by someone else: http://bbs.archlinux.org/viewtopic.php?pid=690047#p690047 The effect happens randomly when switching between windows. However, it is also 100% reproducable for me by the command x11perf -create After this the window has a white shadow frame (see screenshot). The window entry in the taskbar is sometimes garbled with a white pixmap too (see screenshot). If running with kwin composite *disabled*, only the white pixmap is observed -- as window shadow effects are disabled. Kernel log or xserver log do not provide any useful hints. Bisecting the git kernel shows this as culprit: > [c07d7237a639d57dc91ea7efdbc1b3f85c7a095d] Merge branch 'drm-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 > c07d7237a639d57dc91ea7efdbc1b3f85c7a095d is the first bad commit Bisecting branch "drm-linus" further showed this culprit: > cafe6609d6dc0a6a278f9fdbb59ce4d761a35ddd is the first bad commit > commit cafe6609d6dc0a6a278f9fdbb59ce4d761a35ddd > Author: Jerome Glisse <jglisse@redhat.com> > Date: Thu Jan 7 12:39:21 2010 +0100 > > drm/radeon/kms: Schedule host path read cache flush through the ring V2 After reverting this patch on 2.6.33-rc6, the issue was resolved on my hardware configuration. However, I am unsure about the internals of this commit. Information hopefully is sufficient for an expert to track this further. Environment: Linux 2.6.33-rc4..6 with Radeon KMS ("modprobe radeon modeset=1") Mesa master branch xf86-video-ati master branch Xorg server 1.7.4 libdrm 2.4.17 (or master too) KDE 4.3.95 (composite desktop enabled or disabled, see above)
Created attachment 24817 [details] Screenshot of konsole window executing "x11perf -create" Konsole window reproducably has garbled white frame after executing x11perf -create (probably due to large number of window blits).
Created attachment 24818 [details] Screenshot of taskbar part with garbled window entry
Created attachment 24821 [details] Kernel config
Created attachment 24851 [details] Flush HDP before IB Please try if this patch fix the issue (don't revert the other HDP commit, just apply this patch on top of lastest 2.6.33-rc).
Applied patch on top of vanilla 2.6.33-rc6: Unfortunately not fixed, no visible impact. "x11perf -create" still triggered white window frames. Also changing focus between X11 windows still triggered spurious blue/yellow shadow frames around the windows.
First-Bad-Commit : cafe6609d6dc0a6a278f9fdbb59ce4d761a35ddd Handled-By : Jerome Glisse <jglisse@redhat.com>
Created attachment 24870 [details] Force hdp flush on set_domain(CPU) & wait_idle Please apply this patch on top of clean 2.6.33rc* and check that it fix the issue. This patch is like reverting the commit you did point out thus it should definitly solve the issue but it's an hack. Once you checked that it evectively fix the issue change the set_domain #if 1 to #if 0 and retest, then rechange to if 1 and change the if 1 of wait_idle to if 0 and retest, report result. Thanks
Applied second patch on top of vanilla 2.6.33-rc6: - Both #if 1's: *Fixed* - set_domain #if 0, wait_idle #if 1: *Fixed* - set_domain #if 1, wait_idle #if 0: *Not fixed* (same effect as before) The wait_idle part seems important.
I have 2.6.33-rc6 from today's linux-2.6 snapshot from Linus's tree I tried glisse's latest kms hack patch but I still have text glyph corruption so it doesn't seem to fix it for me. I have a radeon HD 3650 mobile (RV635) FireGL.
I never observed text glyph corruption. @Shawn Starr: Are you sure you observed the same effect? Did you e.g. bisect it to the same commit? Or did you observe the same window corruptions as described by me, and at least those are resolved now or still unresolved for you? I guess we should avoid that we mix up all possible (current/future) corruptions into the same ticket.
Corruption is still unresolved see: http://www.sh0n.net/spstarr/radeon/glyph-corruption.jpg
Shawn, please stop spamming this report with your unrelated issue.
I do observe the same issues as the original poster. Though for me the issues does exist whenever I use KMS. It makes not difference if 2.6.32* (the first time I tried KMS with my rv670 based card) or 2.6.33-rc6. It makes no difference if I change acceleration method from OpenGL to XRender. I have not checked the patch provided in this thread, will do so later on and check if the issues persist. In general I do guess that it is not a bug in mesa since without KMS, this issue does not occur. I will get myself rc6, test with your patch and report back. System info: lspci | grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc RV670PRO [Radeon HD 3850] Gentoo "unstable" amd64 Linux 2.6.32 up to (at least) 2.6.33-rc5 with Radeon KMS (grub boot param: radeon.modeset=1) Mesa git version, master branch xf86-video-ati git version, master branch xorg-server-1.7.4.901 (happened with other xorg-server 1.7.x versions, too) libdrm git version, master branch KDE 4.3.5 (composite desktop enabled or disabled), same with previous 4.3.x versions
(In reply to comment #8) > Applied second patch on top of vanilla 2.6.33-rc6: > - Both #if 1's: *Fixed* > - set_domain #if 0, wait_idle #if 1: *Fixed* > - set_domain #if 1, wait_idle #if 0: *Not fixed* (same effect as before) > > The wait_idle part seems important. Okay, after my tests with 2.6.33-rc6 I do have exactly the same results! So the "wait_idle #if 1" part of the patch basically does the trick. Just to be 100% sure I checked if the issues do occur with vanilla 2.6.32, too, and they are there just as with an unpatched 2.6.33-rc6 for me. So it might in fact be that the "real" issue (at least for me) is something else but the change strangely does fix things. As a note on the side: it makes no difference if qt 4.5.x or 4.6.x is used, had the issues with both.
After the last comment I made another doublecheck on vanilla 2.6.32, and in fact Nils is right: Vanilla 2.6.32 also is broken -- I had it in longer use, but either I was wrong in my observation, it was my newer 100% x11perf test scenario, or it was some other masking SW dependency at that time. The effect also looks more like flickering, less permanent at that version. After further retests this means for kernel versions: - 2.6.32 (and some older ones): FAILED. - 2.6.33-rc3: OK. - 2.6.33-rc4..rc6: FAILED. Now I made another inverse bisect session today, looking for the first "good" fix before abovementioned bad commit. Finally found this one: >commit 23956dfa82eab95931aab5fa9886c1e96c41e4dc >Author: Dave Airlie <airlied@redhat.com> >Date: Mon Nov 23 12:01:09 2009 +1000 > > drm/radeon/kms: add HDP flushing for all GPUs. Sounds reasonable. I am unsure whether you want to keep the regression flag of this ticket. Actually, the point releases always used to be "broken" -- only intermediate rc's were fixed and re-broken :)
I can confirm Robert's problem. I've got a Lenovo U330 with Ati 3450. Running either kernel 2.6.32 or 2.6.33rc4-rc6 cause DRI2 (KMS enabled) to show these yellow/white stripes on Kwin shadows. Reverting to DRI (UMS), fixes the problem. I also can reproduce the problem with 100% confidence using gtkperf on either 2.6.32 or 2.6.33rc4-rc6.
Created attachment 24909 [details] Proper fix Can you check that this patch also fix the issue. It's a proper fix, if it does i will ask Dave to put it in the next radeon drm fixes pull.
Applied last patch to vanilla 2.6.33-rc6: In fact fixed. Will report back if I should find any adverse effects on the long run. Thanks, Jérôme.
Great, this patch fixed the problem for me too (applied to clean 2.6.33-rc6) :) Thanks, Jérôme
Yes, the "proper fix" seems to work nicely over here, too. Will report if any issues arise again. Thanks for fixing this, Jérôme.
Applied in 2.6.33-rc7 mainline, regression resolved.
I just switched form 2.6.33-rc7 to 2.6.33 final. I also updated mesa/libdrm/glproto/xf86-video-ati from GIT 20100217 to 20100306. The problem with Kwin yellowish shadows is back. Was this fix reverted?
I have been using 2.6.33 for a while now and not seen any issue so far with KDE/kwin 4.x. So for me things seem to still be fixed.
Agree with Nils: I constantly pull git master branches from mesa and xf86-video-ati, also some minutes ago. With 2.6.33 still fixed. Suggestion: Revert recent updates one by one, bisect, write new ticket (ref to this).