Bug 665320

Summary: Display corruption when moving windows around
Product: [Fedora] Fedora Reporter: Stefan Ring <stefanrin>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: airlied, ajax, david, emmanuel.kowalski, geoff_hart, jarmofin, jimstaffer, mcepl, mukatikus, ogjerstad, onefiftyfour, xgl-maint
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: http://lists.x.org/archives/xorg-devel/2011-May/022245.html
Whiteboard: [cat:rendering]
Fixed In Version: GA Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 21:44:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg
none
messages
none
Xorg.log
none
dmesg
none
Xorg.0.log
none
messages
none
dmesg
none
messages
none
Xorg.log
none
window corruption pic none

Description Stefan Ring 2010-12-23 08:52:03 UTC
Description of problem:
Display corruption.

The symptoms are exactly the same as in bug #638163.

Version-Release number of selected component (if applicable):
1.9.3-3.fc14.x86_64


How reproducible:
Run X and move windows around.

Actual results:
Window contents become when moved to the left quickly enough (seems like it needs to be more than 8 pixels per frame).


Expected results:
Windows contents unchanged during moving.


Additional info:
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

Comment 1 David Nadle 2010-12-26 16:33:01 UTC
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.

Comment 2 David Nadle 2010-12-27 03:44:44 UTC
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.

Comment 3 Øyvind Gjerstad 2011-01-04 07:42:19 UTC
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.

Comment 4 Øyvind Gjerstad 2011-01-24 12:53:56 UTC
This bug is still present in 1.9.3-4. Reverting to 1.9.0-15 works.

Comment 5 Matěj Cepl 2011-01-25 11:16:28 UTC
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.

Comment 6 Stefan Ring 2011-01-25 12:12:58 UTC
Created attachment 475152 [details]
dmesg

Comment 7 Stefan Ring 2011-01-25 12:13:26 UTC
Created attachment 475153 [details]
messages

Comment 8 Stefan Ring 2011-01-25 12:15:34 UTC
Created attachment 475154 [details]
Xorg.log

No /etc/xorg.conf. I booted with drm.debug=0x04, logged in, opened and dragged some windows. The corruption was immediately apparent.

Comment 9 Øyvind Gjerstad 2011-01-25 19:50:41 UTC
Created attachment 475254 [details]
dmesg

Comment 10 Øyvind Gjerstad 2011-01-25 19:51:48 UTC
Created attachment 475255 [details]
Xorg.0.log

Comment 11 Øyvind Gjerstad 2011-01-25 19:56:04 UTC
Created attachment 475257 [details]
messages

Comment 12 Stefan Ring 2011-01-26 12:20:43 UTC
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:

Section "Device"
Identifier "n"
Driver "vesa"
EndSection

After that I opened a Nautilus window and moved it around - that was all it took to reproduce this problem.

Comment 13 Matěj Cepl 2011-01-26 17:32:01 UTC
(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?

Thanks

Comment 14 Stefan Ring 2011-01-26 17:50:46 UTC
Created attachment 475453 [details]
dmesg

From VirtualBox vesa with drm.debug=0x04, as requested

Comment 15 Stefan Ring 2011-01-26 17:51:09 UTC
Created attachment 475454 [details]
messages

From VirtualBox vesa with drm.debug=0x04, as requested

Comment 16 Stefan Ring 2011-01-26 17:51:35 UTC
Created attachment 475455 [details]
Xorg.log

From VirtualBox vesa with drm.debug=0x04, as requested

Comment 17 Matěj Cepl 2011-01-26 22:07:55 UTC
(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.

Comment 18 Øyvind Gjerstad 2011-01-26 22:20:35 UTC
What?? No VESA driver here.

Comment 19 Stefan Ring 2011-01-26 22:37:37 UTC
> 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.

As I said in the original description, it also occurs with fbdev and with nouveau with noaccel.

Comment 20 mukatikus 2011-02-07 02:14:22 UTC
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.

Comment 21 Stefan Ring 2011-02-16 09:47:46 UTC
This isn't related to the VESA driver.

Comment 22 jimstaffer 2011-02-26 22:01:57 UTC
(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: 2.6.35.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!

Comment 23 Øyvind Gjerstad 2011-03-01 12:01:59 UTC
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?

Comment 24 Geoff 2011-03-04 16:13:14 UTC
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*
xorg-x11-server-common-1.9.0-15.fc14.x86_64
xorg-x11-server-utils-7.4-19.fc14.x86_64
xorg-x11-server-Xorg-1.9.0-15.fc14.x86_64
ghart@64 spc1 $ rpm -qa tiger*
tigervnc-server-minimal-1.0.90-0.22.20100813svn4123.fc14.x86_64
tigervnc-server-1.0.90-0.24.20100813svn4123.fc14.x86_64
tigervnc-server-1.0.90-0.22.20100813svn4123.fc14.1.x86_64
tigervnc-license-1.0.90-0.24.20100813svn4123.fc14.noarch
tigervnc-server-module-1.0.90-0.22.20100813svn4123.fc14.x86_64
tigervnc-1.0.90-0.22.20100813svn4123.fc14.x86_64
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!

Comment 25 Geoff 2011-03-04 16:16:14 UTC
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.

Comment 26 jimstaffer 2011-03-12 02:55:16 UTC
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!

Comment 27 Øyvind Gjerstad 2011-03-13 21:48:58 UTC
How can this bug be relateted to nouveau? I have it on ATI HD5870, using the open source radeon driver. See comment #3.

Comment 28 Ben Skeggs 2011-03-13 22:16:00 UTC
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.

Comment 29 jimstaffer 2011-04-03 23:08:44 UTC
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.

Comment 30 Øyvind Gjerstad 2011-04-07 21:27:53 UTC
Just tried xorg-x11-server-Xorg-1.9.5-1.fc14.x86_64. The bug is still present.

Comment 31 Stefan Ring 2011-04-25 09:36:08 UTC
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.

Comment 32 Stefan Ring 2011-04-25 22:01:55 UTC
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

Comment 33 Geoff 2011-05-05 18:57:40 UTC
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

tigervnc-server-1.0.90-0.25.20100813svn4123.fc14.x86_64
xorg-x11-server-Xorg-1.9.5-1.fc14.x86_64

Comment 34 Stefan Ring 2011-05-06 08:35:24 UTC
(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
> 
> tigervnc-server-1.0.90-0.25.20100813svn4123.fc14.x86_64
> xorg-x11-server-Xorg-1.9.5-1.fc14.x86_64

Yes, because bug #652590 has been fixed in tigervnc.

Comment 35 Øyvind Gjerstad 2011-05-08 20:27:14 UTC
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?

Comment 36 Stefan Ring 2011-05-18 08:06:38 UTC
Probably the same as <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626682>, but this guess will need verification.

Comment 37 Stefan Ring 2011-05-20 10:14:56 UTC
(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.

Comment 38 jimstaffer 2011-06-04 03:03:36 UTC
Um, folks... Bump...  Any ETA for the fix?  It would be great to close this issue.

Comment 39 Stefan Ring 2011-07-08 08:23:23 UTC
(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.

Comment 40 Matěj Cepl 2011-07-12 06:19:39 UTC
(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.

Comment 41 Stefan Ring 2011-07-12 08:29:37 UTC
> 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.

Comment 42 Matěj Cepl 2011-07-12 10:02:08 UTC
(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:
> <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.

Well, this is F15 bug. Closing.

Comment 43 Stefan Ring 2011-07-12 10:09:11 UTC
Oh well, maybe I shouldn't have "upgraded" the version to F15...

Comment 44 Matěj Cepl 2011-07-12 10:56:25 UTC
(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?

Comment 45 Stefan Ring 2011-07-12 11:16:11 UTC
(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.

Comment 46 James 2011-10-04 16:51:48 UTC
I guess the bug that I just reported for Fedora 14 

https://bugzilla.redhat.com/show_bug.cgi?id=743333

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?

Comment 47 jimstaffer 2011-10-04 21:23:01 UTC
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.

Comment 48 James 2011-10-06 13:45:18 UTC
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:

http://fedoraproject.org/wiki/Releases#Current_Supported_Releases

Comment 49 Geoff 2011-10-06 14:07:38 UTC
(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:
> 
> http://fedoraproject.org/wiki/Releases#Current_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 2.6.35.13-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
tigervnc-1.0.90-0.25.20100813svn4123.fc14.x86_64

Comment 50 Stefan Ring 2011-10-07 06:49:53 UTC
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):
http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=commit;h=8e9b95c8071eb5a0ed96fffab156a85e6445a94b

Patch in upstream Xorg (1.11): http://cgit.freedesktop.org/xorg/xserver/commit/?id=e32cc0b4c85c78cd8743a6e1680dcc79054b57ce

Comment 51 jimstaffer 2011-10-08 23:48:39 UTC
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?

Tx

Comment 52 Stefan Ring 2011-10-10 06:30:57 UTC
I re-open it for this purpose. Maybe it just didn't get noticed.

Comment 53 James 2011-10-25 10:01:50 UTC
I think this bug got fixed in an update today. Thank you *very* much!

Comment 54 Matěj Cepl 2011-10-25 15:19:09 UTC
Reporter, can you confirm comment 53, please?

Thank you

Comment 56 jimstaffer 2011-10-25 23:34:55 UTC
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!!!

Comment 57 Fedora End Of Life 2012-08-16 21:44:56 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping