Description of problem:
The symptoms are exactly the same as in bug #638163.
Version-Release number of selected component (if applicable):
Run X and move windows around.
Window contents become when moved to the left quickly enough (seems like it needs to be more than 8 pixels per frame).
Windows contents unchanged during moving.
Yesterday's yum upgrade, which I do fairly often, installed these packages for me:
Dec 22 08:22:28 Updated: xorg-x11-server-common-1.9.3-3.fc14.x86_64
Dec 22 08:22:34 Updated: xorg-x11-server-Xvfb-1.9.3-3.fc14.x86_64
Dec 22 08:22:35 Updated: xorg-x11-server-Xorg-1.9.3-3.fc14.x86_64
Dec 22 08:23:41 Updated: xorg-x11-server-debuginfo-1.9.3-3.fc14.x86_64
Dec 22 08:23:47 Updated: xorg-x11-server-source-1.9.3-3.fc14.noarch
Dec 22 08:23:49 Updated: xorg-x11-server-devel-1.9.3-3.fc14.x86_64
I had version 1.9.1-3.fc14 before. This older version did not have the problem.
I’m running a standard GNOME desktop without 3D effects. I also use nouveau.noaccel=1 because of bug #609790. I did a bit of testing and noticed the following:
nouveau with acceleration (without .noaccel): good
nouveau with .noaccel: problem occurs
fbdev: problem occurs
vesa (with nouveau.modeset=0): problem occurs
My hardware: http://www.smolts.org/client/show/pub_dbe294f3-62e0-40f9-b141-547eeb979466
I have the same issue after updating two Fedora 14 Virtual Box guests on two different machines. The VM settings have 3D acceleration disabled. I can confirm that 1.9.1-3 did not exhibit the problem. After perfoming:
yum downgrade xorg-x11-server-Xorg
which brought me back to 1.9.0-15, the display corruption ceased.
An update: I upgraded 32-bit fc14 xorg on a ThinkPad T40 notebook and it does not have the screen corruption. Maybe the bug is only in the 64-bit package? Both my VirtualBox VMs are 64-bit.
I also experience the same symptoms after the same update. Reverting xorg-x11-server-Xorg also fixes the problem for me. I am on an 64 bit HP EliteBook 8740w with ATI HD5870 and stock F14 everything (i.e. KMS and no accel). Since that I have also tried various updates from rawhide, but no success.
This bug is still present in 1.9.3-4. Reverting to 1.9.0-15 works.
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 add drm.debug=0x04 to the kernel command line, restart computer, and attach
* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)
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 475152 [details]
Created attachment 475153 [details]
Created attachment 475154 [details]
No /etc/xorg.conf. I booted with drm.debug=0x04, logged in, opened and dragged some windows. The corruption was immediately apparent.
Created attachment 475254 [details]
Created attachment 475255 [details]
Created attachment 475257 [details]
I want to stress one fact again: this is completely hardware independent. It is easily reproducible on VirtualBox. I just installed a fresh F14 x86_64 instance (with updates repo activated during installation) and created an /etc/X11/xorg.conf file like this:
After that I opened a Nautilus window and moved it around - that was all it took to reproduce this problem.
(In reply to comment #12)
> I just installed a fresh F14 x86_64 instance
> (with updates repo activated during installation) and created an
> /etc/X11/xorg.conf file like this:
Could we get attached logs also for vesa on VirtualBox system?
Created attachment 475453 [details]
From VirtualBox vesa with drm.debug=0x04, as requested
Created attachment 475454 [details]
From VirtualBox vesa with drm.debug=0x04, as requested
Created attachment 475455 [details]
From VirtualBox vesa with drm.debug=0x04, as requested
(In reply to comment #12)
> I want to stress one fact again: this is completely hardware independent. It is
Maybe hardware independent, but not driver one ... in both cases you use VESA drivers (not sure why ... nvidia would probably work with nouveau driver and VirtualBox with vbox driver from rpmfusion .. http://download1.rpmfusion.org/free/fedora/development/x86_64/os/repoview/V.group.html).
Passing to developers for VESA drivers.
What?? No VESA driver here.
> Maybe hardware independent, but not driver one ... in both cases you use VESA
> drivers (not sure why ... nvidia would probably work with nouveau driver and
> VirtualBox with vbox driver from rpmfusion ..
> Passing to developers for VESA drivers.
As I said in the original description, it also occurs with fbdev and with nouveau with noaccel.
I'm having the same problem with a standard GNOME install, no 3D, using nouveau driver.
The problem only affects window managers other than metacity. GNOME (with metacity) works by default. Running GNOME/Openbox exhibits the problem, as does standalone fluxbox, openbox & pekwm. Running metacity by itself (no GNOME) also works.
Downgrading xorg-x11-server-Xorg to 1.9.0-15 fixes the problem.
Passing nouveau.noaccel=0 at boot also fixes the problem.
Perhaps these observations might help.
This isn't related to the VESA driver.
(In reply to comment #12)
> I want to stress one fact again: this is completely hardware independent.
I run two systems on F14 64bit - both very "stock standard" - and I keep them both patched: 220.127.116.11-83.fc14.x86_64 #1 SMP.
Home-brew tower with Gigabyte GA-EP45-DS3P motherboard, GV-NX85T512HP GPU, Intel Q9450 quad core, 4GB RAM - has never experienced this problem.
HP DV6-2114TX laptop: 2.53 GHz Intel Core i5-540M, 4GB RAM - _does_ experience this problem - on both KDE and Gnome. Downgrading xorg-x11-server-Xorg fixed this bug.
From these two different behaviors I conclude that this bug _is_ platform dependent!
So, what are the real significant differences between the two systems in the last example? They are both on nvidia, apparently. Are they running the same driver?
We have been hitting what appears to be the same issue using tigervnc. The corruption is server side, as different client connections "see" the same images. At first I thought it was a window manager issue, so I tried using icewm, but no change. Using "non-opaque" (in icewm) window moves *lessens* the issue, but it still occurs occasionally. KDE also shows the same behavior.
However, if I reduce the depth to 8 bits, I can't reproduce the problem.
I tried downgrading xorg (thinking tigervnc was somehow using it for its backend) but no change. I also downgraded tigervnc: no change.
I'm attaching (if I can figure out how) a screen shot to show the problem (easy to reproduce, just move window horizontally quickly).
Here's (what I think are) the relative versions:
ghart@64 spc1 $ rpm -qa xorg-x11-server*
ghart@64 spc1 $ rpm -qa tiger*
ghart@64 spc1 $ grep Tiger ~spsy/.vnc/mspl001.empros.com:4.log
Xvnc TigerVNC 1.0.90 - built Sep 21 2010 16:11:15
See http://www.tigervnc.org for information on TigerVNC.
If anyone knows a work-around, please respond!
Created attachment 482321 [details]
window corruption pic
just move (any window) quickly horizontally, and you see what appears to be one strip of window edge repeated across the entire window.
I'd be happy to post any relevant information from my two F14 x86 systems (one with the problem, the other without) that would be useful in fixing this bug. Just let me know what info would be helpful.
I have also noticed that when I use tigervnc to administer remote SuSE Enterprise Linux servers, the colors are corrupted. This happens whether I move the tigervnc windows or not! I first switched to vnc, which works normally. Then I discovered that changing the depth from 16 to 24 bits (in /etc/xinetd.d/vnc on the SLES boxes) makes tigervnc work properly too.
I'm currently running tigervnc-1.0.90-0.24.20100813svn4123.fc14.x86_64. I don't know if the problem existed on an earlier version and it's fixed now - or even if I was running an earlier version before. (I didn't take note of the version before.)
It appears to me that these are 2 separate problems. A statement made with very little actual factual evidence!
How can this bug be relateted to nouveau? I have it on ATI HD5870, using the open source radeon driver. See comment #3.
To me it looks like this bug happens to anyone using a non-accelerated driver actually, which seems to point at pixman. I'll reassign there for now.
I just tried xorg-x11-server-Xorg-1.9.4-1.fc14.x86_64 on my HP laptop.
This bug is still present. As before, downgrading to 1.9.0-15 fixed it.
Just tried xorg-x11-server-Xorg-1.9.5-1.fc14.x86_64. The bug is still present.
Still present in a vanilla F15 installation from the F15 Beta DVD image (x86_64) inside VirtualBox (4.0.6). It chose the VESA driver all by itself and exhibited the corruption issue right from the start.
Oh my, it was caused by this lowly commit, unbelievable as that may seem: http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=commit;h=805f8742d107e85c58f50dd7205f627dd5d49115
I just noticed I can't reproduce the problem!!! At least in VNC.
I do not know what is the relevant rpm for the fix though:
Xvnc TigerVNC 1.0.90 - built Apr 13 2011 15:15:08
(In reply to comment #33)
> I just noticed I can't reproduce the problem!!! At least in VNC.
> I do not know what is the relevant rpm for the fix though:
> Xvnc TigerVNC 1.0.90 - built Apr 13 2011 15:15:08
Yes, because bug #652590 has been fixed in tigervnc.
So, the commit is knowm, the artifacts are indeed identical to the ones fixed by bug #652590. The corruption only happens when moving windows left. When can we expect a patch for this in the X server?
Probably the same as <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626682>, but this guess will need verification.
(In reply to comment #36)
> Probably the same as <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626682>,
> but this guess will need verification.
Yes, indeed. The "careful" patch from http://lists.x.org/archives/xorg-devel/2011-May/022245.html solves this problem.
Um, folks... Bump... Any ETA for the fix? It would be great to close this issue.
(In reply to comment #31)
> Still present in a vanilla F15 installation from the F15 Beta DVD image
> (x86_64) inside VirtualBox (4.0.6). It chose the VESA driver all by itself and
> exhibited the corruption issue right from the start.
Considering that F15 Beta was released on Apr 19, I guess it didn't carry this commit from Apr 21 (just barely): http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=commitdiff;h=8e9b95c8071eb5a0ed96fffab156a85e6445a94b
Even though the patch has still not been upstreamed (<http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/21127>), this bug seems to have been silently fixed in F15, as I have just noticed.
(In reply to comment #39)
> Even though the patch has still not been upstreamed
> (<http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/21127>), this bug
> seems to have been silently fixed in F15, as I have just noticed.
So, could be this closed as CURRENTRELEASE? The Debian bug you have referred to has not been closed yet either.
Thank you for bearing with us until here.
> So, could be this closed as CURRENTRELEASE? The Debian bug you have referred to
> has not been closed yet either.
I guess it could. OTOH, it would be trivial to add the patch (this one: <http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=blob;f=xserver-1.10.1-memcpy-abuse.patch;h=e3b1b9772d82680827c236571239d9103a6f10a3;hb=8e9b95c8071eb5a0ed96fffab156a85e6445a94b>) to F14 as well.
(In reply to comment #41)
> > So, could be this closed as CURRENTRELEASE? The Debian bug you have referred to
> > has not been closed yet either.
> I guess it could. OTOH, it would be trivial to add the patch (this one:
> to F14 as well.
Well, this is F15 bug. Closing.
Oh well, maybe I shouldn't have "upgraded" the version to F15...
(In reply to comment #43)
> Oh well, maybe I shouldn't have "upgraded" the version to F15...
Sorry, I don't understand ... this should be fixed in F15, right?
(In reply to comment #44)
> (In reply to comment #43)
> > Oh well, maybe I shouldn't have "upgraded" the version to F15...
> Sorry, I don't understand ... this should be fixed in F15, right?
Yes. I originally reported it against F14 and have changed it to F15 when I discovered that F15 Beta had the same problem.
I guess the bug that I just reported for Fedora 14
is a copy of the issue discussed here. I didn't understand the discussion completely: will this issue be fixed in Fedora 14 at some point? Or is there a known solution already?
What does "Status: CLOSED CURRENTRELEASE" mean for F14?
Given that it's been almost a year, and - as I understand it - this bug has been reported, identified, confirmed, diagnosed and a fix has been written - but it has still not been applied to F14... I'm no longer optimistic.
At least the work-around is trivial, but this is still annoying.
I am quite surprised to see that a fix has been found but not incorporated into Fedora 14, given that F14 is *still* one of the supported releases:
(In reply to comment #48)
> I am quite surprised to see that a fix has been found but not incorporated into
> Fedora 14, given that F14 is *still* one of the supported releases:
And I am surprised, that this has re-appeared. I was experiencing the problem in TigerVNC (comment 33) but it was resolved a few days after I saw comment 39. And as it still works for me (F14), I presume there is a different issue now?
The screen shot for bug 743333 does look the same as I was seeing in VNC though.
$ uname -a
Linux mspl001.empros.com 18.104.22.168-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q tigervnc
It has not re-appeared. It’s just code duplication at work. Xorg xserver and TigerVNC both contain the same piece of code, and the respective package maintainers chose different patches to address the problem (Xorg's is the better one) -- and more importantly: different target releases.
TigerVNC fix (F14): http://pkgs.fedoraproject.org/gitweb/?p=tigervnc.git;a=commit;h=ccc7f646ab95374d9c75973b1a3a12a87ea51e7d
Xorg xserver fix (F15):
Patch in upstream Xorg (1.11): http://cgit.freedesktop.org/xorg/xserver/commit/?id=e32cc0b4c85c78cd8743a6e1680dcc79054b57ce
At the risk of re-stating the bleeding obvious...
There a number of us that would like to have this (Xorg) bug fixed in F14. As James has pointed out, F14 _is_ still a _supported_ release.
So, will this bug (for which the fix appears to have already been written) be fixed in F14? If so, when? If not, why not?
I, for one, would really like to have this fixed. Can it please be fixed?
I re-open it for this purpose. Maybe it just didn't get noticed.
I think this bug got fixed in an update today. Thank you *very* much!
Reporter, can you confirm comment 53, please?
Yes, it got fixed by this changeset: http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=commit;h=ad61bfcd78d4c14d23de12c0543ffe5e457e36e1
I can also confirm this functionality is working properly on both my F14 systems: 1. the tower, where the problem never existed, and
2. the HP laptop where the problem did exist.
More particularly, this worked normally: xorg-x11-server-Xorg-1.9.0-15.fc14.x86_64
Releases after that failed.
This works again: xorg-x11-server-Xorg-1.9.5-2.fc14.x86_64
I wish to also thank everyone involved in fixing this bug!!!
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: