Bug 577142

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach

* your X server config file (/etc/X11/xorg.conf, if available),
* output of the dmesg command,
* system log (/var/log/messages), and
* X server log file (/var/log/Xorg.*.log)
* screenshot illustrating the problem

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 402949 [details]
xorg.log

No xorg.conf (auto detected)
messages is to big - 11mb.
when taking a screenshot, the problem disappears.
xorglog is attached.

(In reply to comment #2)
> No xorg.conf (auto detected)
> messages is to big - 11mb.

In such case, there is gzip for that ;) ... it's better to have compressed log, than nothing.

Thank you

Created attachment 406423 [details]
Same problem on a F13 Beta system

I'm experiencing the same problem on a Fedora 13 Beta box with an Intel GM45 chip, my logs are attached to the bugreport.

Note that this problem didn't occur on Fedora 12 on the same machine. It seems to be some kind of "redraw" problem and happens in the terminal as well as in Gnome's file browser. For example, the files in the browser don't get displayed until you move the windows around to make it force a redraw.

Of course, the problem doesn't happen as soon as compiz is disabled. It's hard to tell if compiz is to blame or the Intel driver, probably a combination of both.

Same here, with a intel graphics test day live cd and a beta fully updated... I'm stuck to ubuntu 10.04, where it works like a charm, because of this... My card doesn't work with f12... I want my fedora back! :(
X logs, messages and dmesg attached in jpg-intelgfx_glitches-20100415-1.tgz

Created attachment 406798 [details]
X logs, messages and dmesg

Created attachment 406867 [details]
terminal output missing

This sounds like it's the same bug as my problem. Various kinds of updates aren't drawn at first, but appear when I switch windows or move windows around. Here's an example of terminal output not being displayed.

Created attachment 406869 [details]
terminal output partly revealed

In this picture, areas that have been covered by other windows are displayed.

Created attachment 406870 [details]
highlighted menus linger

Here, three menus are highlighted when only one should be (if they can be called "highlighted" when they're darker than otherwise). This looks like what Michal Hlavinka describes in bug 582375.

*** Bug 582375 has been marked as a duplicate of this bug. ***

Created attachment 406871 [details]
highlighted menu items linger

Here, two menu items are highlighted when none should be as the mouse pointer has left both of them.

Created attachment 406873 [details]
bubble trails

The "Floating Fedora Bubbles" screensaver sometimes leaves trails. This is probably also the same bug, because this too happens only when Compiz is enabled.

Created attachment 406876 [details]
X server log

And here's my X server log. The Smolt profile is at http://www.smolts.org/client/show/pub_b4a0f0bb-73d1-496e-8d0d-8feee1f6e388, the chip is an 82G35 [8086:2982] (rev 03).

Created attachment 406927 [details]
dmesg

Posting logs from Compiz corruption on the following hardware: http://www.smolts.org/client/show/pub_528c8204-8c24-426f-8785-50d76ead6232 . The corruption looks like this: http://vpv.fedorapeople.org/misc/intel-compiz-corruption.png

Created attachment 406929 [details]
glxinfo

Created attachment 406931 [details]
messages

Created attachment 406932 [details]
xorg.log

These problems are not exhibit when using metacity with composite... It's only a compiz problem... at least on my configuration, http://www.smolts.org/client/show/pub_529b921c-f1de-48ea-be65-429e6a7ffb1b

xorg-x11-drv-intel-2.11.0-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/xorg-x11-drv-intel-2.11.0-1.fc13

*** Bug 582856 has been marked as a duplicate of this bug. ***

Ira reports 2.11.0 improves this problem, can the others of you confirm? Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Perhaps I spoke too soon.  I'm seeing the same behaviour as before, but in slightly different conditions.  There is no noticeable problem when my CPU is idle, but when I make one CPU core (of two) busy the problem rears its head in force.  However, when I make my second core busy, the problem seems to again.

Created attachment 407200 [details]
tooltip clipped and errors in highlighting

This problem is still present in xorg-x11-drv-intel-2.11.0-1.fc13. It may be that it has changed somewhat, but I can't be sure. It has never been possible to trigger it reliably. I thought at first that it happened much less often with 2.11.0-1, but after I plugged in a second monitor it happens quite often.

One effect that I haven't seen before is tooltips getting clipped.

I enter the following in a terminal to make one CPU core busy while still allowing work to get done with it.  I found it's the most reliable way to reproduce this bug on my system.  Do this in additional terminals to tie up additional cores.  Your mileage may vary if you have an Intel processor with Hyper-Threading enabled.

$ nice bash -c "while true; do true; done"

I think number 577142 is a duplicate of this bug. There, it was observed that the glitches first appeared with the switch of mesa 7.8-0.10 -> 7.8-0.11 to the DRI2 API of the intel graphics driver. 

I still get graphics glitches with the newest packages:

xorg-x11-drv-intel-2.11.0-1.fc13.x86_64
xorg-x11-server-Xorg-1.8.0-4.fc13.x86_64
mesa-dri-drivers-7.8.1-1.fc13.i686

This is on i5-520M (Arrandale) integrated video.

Still present here, tested with a fully updated f13 and with this nightly live,
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20100415.20.iso

Hi!, I have installed Fedora 13 Beta, and I've installed the "xorg-x11-drv-intel-2.11.0-1.fc13" package, but the problem still persists when I enable Compiz!... 

Sorry, it doesn't work the version of the Tntel driver, at least for me.

Bug 582749 may at first look like a duplicate of this one, but closer study shows that they differ in several ways. This bug has the following characteristics (at least on my system):

· It happens with Compiz, not with Metacity.
· It does not depend on screen rotation.
· It's unpredictable so reproducing it may require some patience.
· It can affect the entire changed area or any part of it. Often it's an entire window that doesn't get updated.
· The corruption lasts until some event causes the area in question to be redrawn, regardless of what happens elsewhere on the screen.

Created attachment 407426 [details]
Compiz and G45M

Nothing changed with xorg-x11-drv-intel-2.11.0-1.fc13 on a G45M chip for me, you still need to wander your mouse over an area to get it refreshed when you have compiz enabled.

Same here with GMA X3150, and xorg-x11-drv-intel-2.10.0-4.fc13, not tested with 2.11 because of using LiveCD.

The workaround of starting compiz with indirect rendering
 $ LIBGL_ALWAYS_INDIRECT=1 compiz --replace
seems to work if someone really wants to use compiz.

Also i found http://bugs.freedesktop.org/show_bug.cgi?id=27425 which has some clues for the problem and also a fix i suppose.

*** Bug 573366 has been marked as a duplicate of this bug. ***

xorg-x11-drv-intel-2.11.0-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-intel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/xorg-x11-drv-intel-2.11.0-1.fc13

xorg-x11-drv-intel-2.11.0-1.fc13 does not fix the damage processing issues for me either.

(In reply to comment #36)
> xorg-x11-drv-intel-2.11.0-1.fc13 does not fix the damage processing issues for
> me either.    

Well the bug is in mesa ... so I fail to see how a updated X driver could fix it.

This bug seems to affect GeForce4 MX 420 too (but not GeForce 6200, for example).

(In reply to comment #38)
> This bug seems to affect GeForce4 MX 420 too (but not GeForce 6200, for
> example).    

Using which driver?

Using xorg-x11-drv-nouveau and mesa-dri-drivers-experimental.

GeForce4 MX 420 uses Mesa, GeForce 6200 uses Gallium3D.

Should this bug be reassigned to the Mesa component then?

xorg-x11-drv-intel-2.11.0-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-intel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/xorg-x11-drv-intel-2.11.0-1.fc13

*** Bug 584896 has been marked as a duplicate of this bug. ***

Can the affected people please test this mesa build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2132769

It does fix the issue for me, but having others confirm it wouldn't hurt.

It contains the fix mentioned http://bugs.freedesktop.org/show_bug.cgi?id=27425 (re based to current mesa).

Created attachment 408415 [details]
Double-panel action

Maybe a different issue, but this screenshot was made with the new mesa packages installes and compiz enabled.

Hardware is a Lenovo ThinkPad X200 with a X4500.

As Felix pointed out, it fixed my previous problem but completely messes up the Gnome panels...sometimes one panels display in place of the other, sometimes one panels mixes itself with the other etc...

But the refresh problem in the file browser disappeared. I have the same chip as Felix, on a ThinkPad x301.

Applied updates:
 glx-utils        i686 7.8.1-2.fc13   /glx-utils-7.8.1-2.fc13.i686         44 k
 mesa-dri-drivers i686 7.8.1-2.fc13   /mesa-dri-drivers-7.8.1-2.fc13.i686  31 M
 mesa-libGL       i686 7.8.1-2.fc13   /mesa-libGL-7.8.1-2.fc13.i686       484 k
 mesa-libGLU      i686 7.8.1-2.fc13   /mesa-libGLU-7.8.1-2.fc13.i686      416 k

@Adel Gadllah

Sorry, I'm a bit of a newbie, but how do I test with that build, do I have to install all of these:

glx-utils-7.8.1-2.fc13.x86_64.rpm 
mesa-7.8.1-2.fc13.src.rpm 
mesa-debuginfo-7.8.1-2.fc13.x86_64.rpm 
mesa-demos-7.8.1-2.fc13.x86_64.rpm 
mesa-dri-drivers-7.8.1-2.fc13.x86_64.rpm 
mesa-dri-drivers-experimental-7.8.1-2.fc13.x86_64.rpm 
mesa-libGL-7.8.1-2.fc13.x86_64.rpm 
mesa-libGL-devel-7.8.1-2.fc13.x86_64.rpm 
mesa-libGLU-7.8.1-2.fc13.x86_64.rpm 
mesa-libGLU-devel-7.8.1-2.fc13.x86_64.rpm 
mesa-libOSMesa-7.8.1-2.fc13.x86_64.rpm 
mesa-libOSMesa-devel-7.8.1-2.fc13.x86_64.rpm 

If so, how can I remove those packages so I can update correctly when the fix is in?

Thanks!

You can see what you already have installed with rpm -qa | grep "keyword"

Where keyword is something like "mesa", "glx" or whatever you want. Then you download the new rpm's corresponding to what you have installed and update them with "yum --nogpgcheck update blah.rpm"

Or just pull them all down from Koji and do 'rpm -Fvh *.rpm'.  That will only update packages you already have installed.

(In reply to comment #44)
> Can the affected people please test this mesa build:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2132769
> 
> It does fix the issue for me, but having others confirm it wouldn't hurt.
> 
> It contains the fix mentioned http://bugs.freedesktop.org/show_bug.cgi?id=27425
> (re based to current mesa).    

Kristian confirmed on IRC that the fix is correct, so I reassign this to mesa and issue the build as update.

mesa-7.8.1-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/mesa-7.8.1-2.fc13

I'm also seeing improvement with the mesa update. I don't see any glitches in normal windows, but new glitches that appear to only affect the Gnome panels.

(In reply to comment #45)
> Created an attachment (id=408415) [details]
> Double-panel action
> 
> Maybe a different issue, but this screenshot was made with the new mesa
> packages installes and compiz enabled.
> 
> Hardware is a Lenovo ThinkPad X200 with a X4500.    

(In reply to comment #46)
> As Felix pointed out, it fixed my previous problem but completely messes up the
> Gnome panels...sometimes one panels display in place of the other, sometimes
> one panels mixes itself with the other etc...
> 
> But the refresh problem in the file browser disappeared. I have the same chip
> as Felix, on a ThinkPad x301.
> 
> Applied updates:
>  glx-utils        i686 7.8.1-2.fc13   /glx-utils-7.8.1-2.fc13.i686         44 k
>  mesa-dri-drivers i686 7.8.1-2.fc13   /mesa-dri-drivers-7.8.1-2.fc13.i686  31 M
>  mesa-libGL       i686 7.8.1-2.fc13   /mesa-libGL-7.8.1-2.fc13.i686       484 k
>  mesa-libGLU      i686 7.8.1-2.fc13   /mesa-libGLU-7.8.1-2.fc13.i686      416 k    

(In reply to comment #52)
> I'm also seeing improvement with the mesa update. I don't see any glitches in
> normal windows, but new glitches that appear to only affect the Gnome panels.    


OK, I was able to reproduce this but only with xorg-x11-server-1.8.0-7.fc13 xorg-x11-server-1.8.0-6.fc13 (and anything older is fine).

(In reply to comment #53)
> [...]
> OK, I was able to reproduce this but only with xorg-x11-server-1.8.0-7.fc13
> xorg-x11-server-1.8.0-6.fc13 (and anything older is fine).    

This seems to be this issue http://lists.x.org/archives/xorg-devel/2010-April/007663.html (would explain why it only happens with compiz).

There is a proposed fix here: http://lists.x.org/archives/xorg-devel/2010-April/007554.html

I'm actually seeing this bug myself, now, on a Thinkpad X60 I'm using at present. What's the current state-of-the-art in packages we should be testing to see if it's fixed?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #55)
> I'm actually seeing this bug myself, now, on a Thinkpad X60 I'm using at
> present. What's the current state-of-the-art in packages we should be testing
> to see if it's fixed?

With mesa-7.8.1-2.fc13 (which should hit updates testing soon) and xorg-x11-server-1.8.0-6.fc13 it shouldn't happen.

xorg-x11-server-1.8.0-7.fc13 (current xserver build) triggers another bug (the panel issue people are talking about), which is caused by the DRI2 resources fixes (see comment 54).

Ajax said he will look into it.

Bad news, and good news... the bad is that... (I hate to say this but), I have the gnome panel problem when I update the mesa package to mesa-7.8.1-2.fc13...

The good news is that I don't see the glitches anymore!

(In reply to comment #54)
> (In reply to comment #53)
> > [...]
> > OK, I was able to reproduce this but only with xorg-x11-server-1.8.0-7.fc13
> > xorg-x11-server-1.8.0-6.fc13 (and anything older is fine).    
> 
> This seems to be this issue
> http://lists.x.org/archives/xorg-devel/2010-April/007663.html (would explain
> why it only happens with compiz).
> 
> There is a proposed fix here:
> http://lists.x.org/archives/xorg-devel/2010-April/007554.html    

I have created a scratch build with the proposed patch and it indeed fixes the problem for me.

So the update mesa + this xserver build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2134147

Fixes the whole issue for me.

I can confirm that the new xorg build fixes all the issues for me as well.

Discussed at the blocker meeting today. We agreed that as this is a regression in a previously very solid chipset, affecting features a lot of people probably expect to be working at this point, we can take it as a blocker. It looks like the combination of the mesa update and the X.org fix in Adel's scratch build fix everything discussed here. Adel will commit the X.org fix and an updated xorg should hit testing soon after that.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

xorg-x11-server-1.8.0-8.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.8.0-8.fc13

seems good here with the new mesa and x server.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

GOOD NEWS! I have no glitches or problems with the gnome panel using the new packakes posted here (mesa and x server).

This update does seem to fix both the problems, the redrawing in normal apps as well as panel duplicity. 
However there are still issues with some apps using 3D graphics features, most notable i've tried a few SDL apps, and they all have issues redrawing under compiz (work fine w/o compiz). Basically there are no redraws under compiz.
Anyone can test (i've tried using the simple tuxpack game using SDL) and confirm this problem?

(In reply to comment #64)
> This update does seem to fix both the problems, the redrawing in normal apps as
> well as panel duplicity. 
> However there are still issues with some apps using 3D graphics features, most
> notable i've tried a few SDL apps, and they all have issues redrawing under
> compiz (work fine w/o compiz). Basically there are no redraws under compiz.
> Anyone can test (i've tried using the simple tuxpack game using SDL) and
> confirm this problem?    

Okey, I confirm the problem that you mentioned, I did the test with SuperTuxKart, and the screen seems shaky...

(In reply to comment #64)
> This update does seem to fix both the problems, the redrawing in normal apps as
> well as panel duplicity. 
> However there are still issues with some apps using 3D graphics features, most
> notable i've tried a few SDL apps, and they all have issues redrawing under
> compiz (work fine w/o compiz). Basically there are no redraws under compiz.
> Anyone can test (i've tried using the simple tuxpack game using SDL) and
> confirm this problem?    

I cannot reproduce this here ....
SDL apps work fine in compiz windowed as well as fullscreen.
Same goes for apps that use GLX directly as well as clutter based ones.

(In reply to comment #65)
> (In reply to comment #64)
> > This update does seem to fix both the problems, the redrawing in normal apps as
> > well as panel duplicity. 
> > However there are still issues with some apps using 3D graphics features, most
> > notable i've tried a few SDL apps, and they all have issues redrawing under
> > compiz (work fine w/o compiz). Basically there are no redraws under compiz.
> > Anyone can test (i've tried using the simple tuxpack game using SDL) and
> > confirm this problem?    
> 
> Okey, I confirm the problem that you mentioned, I did the test with
> SuperTuxKart, and the screen seems shaky...    

define "shaky" ...

Haven't tried any SDL games, but I do notice that GNOME Shell won't run at all on my system. Anyone else see that?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #67)
> Haven't tried any SDL games, but I do notice that GNOME Shell won't run at all
> on my system. Anyone else see that?

I tried it ... it does in fact run but takes forever to start.

Open a terminal and type "gnome-shell --replace" and just wait after ~5min it should show up and work.

Still need to find out what is going on though.

Can you confirm that it works for you to using the terminal + wait method?

(In reply to comment #68)
> (In reply to comment #67)
> > Haven't tried any SDL games, but I do notice that GNOME Shell won't run at all
> > on my system. Anyone else see that?
> 
> I tried it ... it does in fact run but takes forever to start.
> 
> Open a terminal and type "gnome-shell --replace" and just wait after ~5min it
> should show up and work.
> 
> Still need to find out what is going on though.
> 
> Can you confirm that it works for you to using the terminal + wait method?    

OK Adam confirmed on IRC that he is seeing the same and that "mutter --replace" works just fine.

Adding Owen to CC as he might have an idea what is going on.

It doesn't take forever to start but rather forever to appear. Because I can click on stuff and my mouse pointer changes when hovering things. I just can't see anything.

The gnome-shell issue seems to happen without the updated packages too so it is a different bug and should be filled against gnome-shell. (I am not sure if the bug is in gnome-shell or somewhere else though).

xorg-x11-server-1.8.0-8.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

mesa-7.8.1-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Created attachment 410002 [details]
grey rectangle left behind when a dialog box has changed size

I still see clipped tooltips, as shown in attachment 407200 [details]. It's always the right and/or lower part of the tooltip box that's missing.

I now have these packages installed:
xorg-x11-server-Xorg-1.8.0-8.fc13.x86_64
xorg-x11-server-common-1.8.0-8.fc13.x86_64
xorg-x11-drv-intel-2.11.0-2.fc13.x86_64
mesa-libGL-7.8.1-2.fc13.x86_64
mesa-libGLU-7.8.1-2.fc13.x86_64
mesa-dri-drivers-7.8.1-2.fc13.x86_64

I haven't been able to reproduce any of the other symptoms with these package versions (so far), only the clipped tooltips, so it may be that there were two bugs with very similar symptoms and one of them has been fixed.

On the other hand I've noticed another symptom which may or may not be new: When I click on a link to an attachment, Firefox opens a dialog box asking me what to do with the file. The dialog box shrinks a bit vertically immediately after it opens, and sometimes the grey colour is left in the area that was briefly covered by the dialog box. Like the other symptoms listed here it's unpredictable, seems to happen only with Compiz, and lasts until the affected area gets redrawn. I'm attaching a picture.

I have a big problem here, when I enable Compiz, sometimes my laptop doesn't respond after 15 or 20 minutes that I activate it.  

When I check Xorg log file,  and dmesg log file, it doesn't show anything wrong... 

only the messages log file shows me something, but I don't know if this is related to the bug:

Apr 28 21:33:14 localhost kernel: DMA-API: debugging out of memory - disabling
Apr 28 21:33:20 localhost kernel: compiz used greatest stack depth: 5008 bytes left

The worst, is that the laptop doesn't respond even when I press SysRQ magic keys to try reboot the system (ALT+Pet Sis+B) ... 

When I work on my laptop without Compiz, this situation it doesn't appear.

The last few reported issues seem a bit different from the original bug, can you please open new bugs instead of keeping this report on life support? :) Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

The issue i mentioned in comment #64 is probably a result of the fix for this bug. This problem was not there before. I can see the problem many times when i try to play the game (the trick to reproduce it is to try to move the mouse focus away from the window often). Another way to see this problem is to try to open youtube videos in fullscreen, which does not update the display at all. This is probably something other people can try to reproduce.

(In reply to comment #77)
> The issue i mentioned in comment #64 is probably a result of the fix for this
> bug. This problem was not there before. I can see the problem many times when i
> try to play the game (the trick to reproduce it is to try to move the mouse
> focus away from the window often). Another way to see this problem is to try to
> open youtube videos in fullscreen, which does not update the display at all.
> This is probably something other people can try to reproduce.    

OK, I can reproduce the youtube issue.

Did the mesa update cause it for you or the xserver one? (or combo of both) ?

I'm not sure about which update broke it. yum downgrade is also not doing anything for me to be able to test them. Can you suggest a way to test.

(In reply to comment #79)
> I'm not sure about which update broke it. yum downgrade is also not doing
> anything for me to be able to test them. Can you suggest a way to test.    

I did some more testing and it seems the flash bug is unrelated ... first time I fullscreen it it works, second time it hangs (same in metacity) in case of metacity it even blocks input when it hangs.

(In reply to comment #80)
> (In reply to comment #79)
> > I'm not sure about which update broke it. yum downgrade is also not doing
> > anything for me to be able to test them. Can you suggest a way to test.    
> 
> I did some more testing and it seems the flash bug is unrelated ... first time
> I fullscreen it it works, second time it hangs (same in metacity) in case of
> metacity it even blocks input when it hangs.    

Yeah the flash issue is https://bugzilla.mozilla.org/show_bug.cgi?id=519601

So unrelated ... good news is that is should be fixed in firefox-3.6.4 once released.

Both the updates to fix the initial bug have been pushed stable and everyone agrees they fix the bug reported here, so I'm closing this. Thanks everyone.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Created attachment 439605 [details]
dragging an xterm across a compiz/gma desktop

I'm running a fully updated fedora 13 and am seeing problems primarily with xterms (but also occasionally with menus) that seem to fit into this bug. 
the streaking on the desktop is not the only problem, within xterms text becomes shrunk by line or garbled when color is used.