Created attachment 323663 [details] Sample of the corruption of a window Description of problem: I normally have many windows open (over a dozen), some full screen, across six workspaces. With Compiz active, the windows and/or window decorations will become corrupted. When the corruption occurs, performance of all Compiz operations also drops significantly. Version-Release number of selected component (if applicable): kernel-2.6.27.5-109.fc10.x86_64 xorg-x11-server-Xorg-1.5.3-3.fc10.x86_64 xorg-x11-drv-i810-2.5.0-3.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1.Start Compiz 2.Open many windows across 6 workspaces 3.Switch workspaces, rotate the cube, watch a video. Eventually the problem occurs. Actual results: Windows and or window decorations become corrupted (see screencap, attached). Expected results: No corruption of the display. Additional info: dmesg, lspci, dmidecode, Xorg.0.log will be attached
Created attachment 323664 [details] dmesg after the corruption occurs
Created attachment 323665 [details] dmidecode
Created attachment 323666 [details] lspci
Created attachment 323667 [details] Xorg.0.log There is no xorg.conf in use.
In the Nvidia Linux forum, someone had complained about the same thing. Yesterday, Nvidia responded with this, which I thought was interesting: "This shouldn't be new, and this behavior is not actually caused by the NVIDIA driver: in the Debian/Ubuntu and RHEL/Fedora repositories, the X server is patched to remove the functionality that initializes the contents of new redirected windows to avoid doing blits from the framebuffer to system memory window pixmaps. Since those blits aren't a performance problem with the NVIDIA driver, we've restored this functionality on the driver side in the 180.xx release series."
(In reply to comment #5) > In the Nvidia Linux forum, someone had complained about the same thing. > Yesterday, Nvidia responded with this, which I thought was interesting: Sorry, what nvidia problems with Fedora Xorg server has common with this bug which is about intel driver?
The Nvidia folks indicated that the problem was not in the Nvidia driver, but rather the result of a Fedora patch, according to the quote above. I'm not saying that it's true, but I'm having the problem with the Intel driver, and folks are also having the problem with the proprietary Nvidia driver. They could certainly be two separate issues, I just thought the information might be useful in isolating the issue, if you're familiar with the patch they are referring to.
I reduced the number of workspaces to four, and kept the number of open windows under 10. Running that way, I can no longer recreate the corruption. Too many open windows triggers the problem, which sounds like a memory management issue to me. I should note that I also have 8GB of RAM in this machine; don't know if the Intel driver has an issue with that.
Just noting that the corruption still occurs with kernel-2.6.27.5-113.fc10.x86_64.
Same with xorg server 1.5.3-5.
I'm now running with kernel-2.6.27.5-116.fc10.x86_64, and so far I've not been able to recreate the corruption. I'll give it a day and report back.
I've been logged in to the same session, running with 16-20 windows since installing the -116 kernel. I've had only 4 incidents of corruption, but they are different. Previously, once a window became corrupted (after a few minutes of use), continued use would spread the problem. More windows and even the desktop background would turn to illegible noise. At that point, ctrl-alt-backspace was the only way out. Now, within a minute or so of each corruption, the window "heals" - the correct contents are restored. The problem does not spread, and the login session remains usable. I don't know how you'd like to categorize this. Is this a new issue (close this bug and open a new bug), or has the existing problem simply reduced in severity?
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Resizing the window slightly is the fastest and easiest way to correct the corruption. If the desktop background get corrupted, switching to another background and back corrects it. The problem occurs after a switching workspaces. If I rotate the cube (ctrl-alt-drag) and hold it, I can observe various windows around the cube corrupting. Sometimes the correct contents are restored, sometimes not. Current software: kernel-2.6.27.7-130.fc10.x86_64 xorg-x11-drv-i810-2.5.0-3.fc10.x86_64 mesa-libGL-7.2-0.14.fc10.i386 mesa-libGLU-7.2-0.14.fc10.x86_64 mesa-dri-drivers-7.2-0.14.fc10.x86_64 mesa-libGLU-7.2-0.14.fc10.i386 mesa-libGL-7.2-0.14.fc10.x86_64 compiz-fusion-extras-0.7.6-6.fc10.x86_64 compiz-0.7.6-17.fc10.x86_64 compiz-manager-0.6.0-8.fc10.noarch gnome-compiz-manager-0.10.4-4.fc10.x86_64 compiz-fusion-gnome-0.7.6-7.fc10.x86_64 compizconfig-python-0.7.6-1.fc10.x86_64 compiz-fusion-0.7.6-7.fc10.x86_64 compiz-gnome-0.7.6-17.fc10.x86_64 compiz-fusion-extras-gnome-0.7.6-6.fc10.x86_64 libcompizconfig-0.7.6-2.fc10.x86_64
I updated the URL for this bug to point to the FreeDesktop bug 18843, which in comment 6 indicates: ------- Comment #6 From Eric Anholt 2008-12-18 19:26:37 PST [reply] ------- My guess is a later I830TexOffsetStart is kicking out an earlier one, as there doesn't appear to be any protection to keep the buffer pinned while its offset is used in the GLX context's batchbuffer. This should be fixed with DRI2. --- I don't know if that's something that can be patched in the interim, since DRI2 isn't even in the approved list for F11, pushing a fix out over a year.
I am still seeing this with the following using KDE desktop effects: kernel-2.6.27.15-170.2.24.fc10.x86_64 xorg-x11-drv-i810-2.5.0-4.fc10.x86_64 xorg-x11-server-Xorg-1.5.3-11.fc10.x86_64 xorg-x11-server-common-1.5.3-11.fc10.x86_64 mesa-libGL-7.2-0.15.fc10.x86_64 mesa-libGLU-7.2-0.15.fc10.x86_64 mesa-dri-drivers-7.2-0.15.fc10.x86_64 I have seen it occur with as few as 2 or 3 windows open. Also, the wallpaper and panel of plasma can get corrupted, usually not at the same time.
Created attachment 336924 [details] Xorg.0.log Just a status update. I'm currently running current rawhide: kernel-2.6.29-9.fc11.x86_64 mesa-dri-drivers-7.5-0.2.fc11.x86_64 mesa-libGL-7.5-0.2.fc11.x86_64 mesa-libGL-devel-7.5-0.2.fc11.x86_64 mesa-libGLU-7.5-0.2.fc11.x86_64 mesa-libGLU-devel-7.5-0.2.fc11.x86_64 xorg-x11-drv-intel-2.6.99.902-1.fc11.x86_64 I tried enabling compiz, and it seemed to be working well. After about 5 hours, the screen corruption re-occured. Since this is now using DRI2, that doesn't seem to be the root cause.
Sorry, please ignore the previous comment. DRI2 was not enabled, because UXA was not enabled. UXA corrupts everything, even with tiling disabled, so I can't use that.
With the latest update, KMS+UXA is working well without Compiz. If Compiz is enabled, windows are not properly updated. I see this most often in terminal windows. For example, I'll ssh to another system and get an all white terminal window and the cursor will move to the prompt location, but there is no text on the screen. Clearing the screen causes text to appear, but portions end up getting lost again with use. kernel-2.6.29.1-52.fc11.x86_64 libdrm-2.4.5-4.fc11.i586 libdrm-2.4.5-4.fc11.x86_64 mesa-dri-drivers-7.5-0.7.fc11.i586 mesa-dri-drivers-7.5-0.7.fc11.x86_64 mesa-libGL-7.5-0.7.fc11.i586 mesa-libGL-7.5-0.7.fc11.x86_64 mesa-libGLU-7.5-0.7.fc11.i586 mesa-libGLU-7.5-0.7.fc11.x86_64 xorg-x11-drv-intel-2.6.99.902-2.fc11.x86_64
Reporter, any changes with recent updates?
I've installed an Nvidia card, and I'm using the proprietary driver, with no problems. I will no longer be able to update this report, so I'm closing it.
I also an no longer seeing this with my Intel card (KWin) so I don't think it's occurring anymore.