Bug 49786

Created attachment 61439 [details]
snapshot showing the corrupt display (see the top part of the window)

Created attachment 61440 [details]
snapshot showing the correct contents after a full redraw

If I disable acceleration with an xorg.conf file containing

Section "Device"
        Identifier      "Device0"
        Driver          "nouveau"
        Option          "NoAccel" "true"
EndSection

this display problem doesn't occur.

Can you confirm that this happens with the latest DDX (1.0.9)? If so, we'll need a bit more information -- please attach both a dmesg + Xorg.0.log for your system. (Even if there are no errors, they contain information that describes your system.)

Created attachment 84379 [details]
dmesg output - DELL Latitude E6400 (2013-08-21)

Created attachment 84380 [details]
Xorg.0.log - DELL Latitude E6400 (2013-08-21)

Created attachment 84381 [details]
Shell script to reproduce the bug (needs xterm and base64)

Created attachment 84383 [details]
Shell script to reproduce the bug (needs xterm and base64)

(In reply to comment #4)
> Can you confirm that this happens with the latest DDX (1.0.9)? If so, we'll
> need a bit more information -- please attach both a dmesg + Xorg.0.log for
> your system. (Even if there are no errors, they contain information that
> describes your system.)

The problem still occurs. I don't know what is the DDX, but Xorg.0.log says:

[    47.996] (II) Module nouveau: vendor="X.Org Foundation"
[    47.996]    compiled for 1.12.4, module version = 1.0.9
[    47.996]    Module class: X.Org Video Driver
[    47.996]    ABI class: X.Org Video Driver, version 12.1

I've attached both dmesg output and the Xorg.0.log file after rebooting the machine and testing.

I've also attached a new shell script to test: it automatically opens the xterm windows at the right place (bitmap fonts may need to be enabled, otherwise I don't know if the bug still occurs). It needs the base64 utility (from the coreutils) to output the data to the first xterm window. Just wait for a few seconds for the second xterm then the text to appear.

Some other thing: the dmesg and Xorg.0.log I've attached correspond to the DELL Latitude E6400. The bug also occurs on a different machine (not with me here); I'll try to attach information in the next few days.

Great repro script! Bug confirmed on my NV96, and disconfirmed on NV18. I see that your card is a NV98, so this is probably a bug in the nv50 exa logic.

FYI, the other machine where the bug occurs also has a NV98 chipset. The exact card is the following:

  NVIDIA Corporation G98 [Quadro NVS 295] (rev a1)

according to lspci. The one on the DELL Latitude is:

  NVIDIA Corporation G98M [Quadro NVS 160M] (rev a1)

And as I suspected, if you run a compositor, the issue goes away (e.g. with xcompmgr).

Also tested on NV42, doesn't happen there either. Further points to something in the nv50 exa rather than something generic...

still a problem with recent xf86-video-nouveau? Imirkin, maybe you could test this and just provide a status update

(In reply to Tobias Klausmann from comment #15)
> still a problem with recent xf86-video-nouveau? Imirkin, maybe you could
> test this and just provide a status update

Nothing has been changed relevant to this, so I don't see why it wouldn't be.

(In reply to Tobias Klausmann from comment #15)
> still a problem with recent xf86-video-nouveau?

This still occurs in Debian/unstable (xserver-xorg-video-nouveau 1:1.0.11-1).

(In reply to Vincent Lefevre from comment #17)
> This still occurs in Debian/unstable (xserver-xorg-video-nouveau 1:1.0.11-1).

But in November 2013, I noticed that this bug did not occur every time (after killing the compositor):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640464#150

The bug still occurs with the xserver-xorg-video-nouveau 1:1.0.12-1 Debian package and the NVD9 chipset. The video card is:

NVIDIA Corporation GF119 [NVS 315] (rev a1)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/23.