Garbage on X display w/ Dell D800 wuxga & nouveau driver (Nvidia GeForce4 Ti 4200 Go AGP rev a1 [NV28])

[John N]

Binary package hint: xserver-xorg-video-nouveau

I have a Dell D800 laptop with high resolution screen (1920x1200) that was working fine with Ubuntu 10.04. I performed a fresh install of Ubuntu 10.10 which appears to use the nouveau driver. The screen now displays garbage, more pronounced on icons, where text seems to render fairly well.

I've attached a picture of the screen to illustrate.

While I've tried to intall the Nvidia drivers, this problem manifested from the initial install of the 10.10 alternate RC disc, and remains present with all packages updated as of 10/1 where no alternate driver install was attempted.

Please let me know what information I might be able to provide that would be useful in fixing this problem.

Thank you,

-john

root@johnn-craylap:~# lspci | grep -i nvid
01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 Go AGP 8x] (rev a1)
root@johnn-craylap:~#

root@johnn-craylap:~# lsmod | grep -i nv
root@johnn-craylap:~# lsmod | grep -i nouv
nouveau 516971 2
ttm 56633 1 nouveau
drm_kms_helper 30200 2 ch7006,nouveau
drm 168054 5 ch7006,nouveau,ttm,drm_kms_helper
i2c_algo_bit 5168 1 nouveau
root@johnn-craylap:~#

root@johnn-craylap:~# dpkg --status xserver-xorg-video-nouveau
Package: xserver-xorg-video-nouveau
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 284
Maintainer: Ubuntu X-SWAT <email address hidden>
Architecture: i386
Version: 1:0.0.16+git20100805+b96170a-0ubuntu1
Provides: xorg-driver-video, xserver-xorg-video-8
Depends: libc6 (>= 2.4), libdrm-nouveau1 (>= 2.4.20-3~), libudev0 (>= 147), xorg-video-abi-8.0, xserver-xorg-core (>= 2:1.8.99.904)
Description: X.Org X server -- Nouveau display driver (experimental)
 This driver for the X.Org X server (see xserver-xorg for a further description)
 provides support for NVIDIA Riva, TNT, GeForce, and Quadro cards.
 .
 Although the nouveau project aims to provide full 3D support it is not yet
 complete, and these packages do not include any 3D support.
 Users requiring 3D support should use the non-free "nvidia" driver.
 .
 This package is built from the FreeDesktop.org xf86-video-nouveau driver.
Homepage: http://nouveau.freedesktop.org/wiki/
Original-Maintainer: Debian X Strike Force <email address hidden>
root@johnn-craylap:~#

root@johnn-craylap:~# dpkg --status libdrm-nouveau1
Package: libdrm-nouveau1
Status: install ok installed
Priority: required
Section: libs
Installed-Size: 92
Maintainer: Ubuntu X-SWAT <email address hidden>
Architecture: i386
Source: libdrm
Version: 2.4.21-1ubuntu2
Depends: libc6 (>= 2.3.4), libdrm2 (>= 2.4.3)
Breaks: xserver-xorg-video-nouveau (<< 1:0.0.16)
Description: Userspace interface to nouveau-specific kernel DRM services -- runtime
 This library implements the userspace interface to the nouveau-specific kernel
 DRM services. DRM stands for "Direct Rendering Manager", which is the
 kernelspace portion of the "Direct Rendering Infrastructure" (DRI). The DRI is
 currently used on Linux to provide hardware-accelerated OpenGL drivers.
Original-Maintainer: Debian X Strike Force <email address hidden>
root@johnn-craylap:~#

root@johnn-craylap:~# hwinfo
============ start debug info ============
libhd version 16.0 (ia32)
using /var/lib/hardware
kernel version is 2.6
----- /proc/cmdline -----
  BOOT_IMAGE=/vmlinuz-2.6.35-22-generic root=/dev/mapper/80gblaphdd-rootvol ro splash
----- /proc/cmdline end -----
[...]
  3: udi = '/org/freedesktop/Hal/devices/computer'
  info.capabilities = { 'cpufreq_control' }
  info.interfaces = { 'org.freedesktop.Hal.Device.SystemPowerManagement', 'org.freedesktop.Hal.Device.CPUFreq' }
  info.subsystem = 'unknown'
  info.product = 'Computer'
  info.udi = '/org/freedesktop/Hal/devices/computer'
  org.freedesktop.Hal.version = '0.5.14'
  org.freedesktop.Hal.version.major = 0 (0x0)
  org.freedesktop.Hal.version.minor = 5 (0x5)
  org.freedesktop.Hal.version.micro = 14 (0xe)
  system.kernel.name = 'Linux'
  system.kernel.version = '2.6.35-22-generic'
  system.kernel.version.major = 2 (0x2)
  system.kernel.version.minor = 6 (0x6)
  system.kernel.version.micro = 35 (0x23)
  system.kernel.machine = 'i686'
  power_management.can_suspend = true
  power_management.can_suspend_hybrid = false
  power_management.can_hibernate = true
  system.hardware.primary_video.vendor = 4318 (0x10de)
  system.hardware.primary_video.product = 646 (0x286)
  system.hardware.serial = '[redacted]'
  system.hardware.uuid = '[redacted]'
  system.board.serial = '[redacted]'
  system.firmware.vendor = 'Dell Computer Corporation'
  system.firmware.version = 'A13'
  system.firmware.release_date = '06/30/2005'
  system.hardware.vendor = 'Dell Computer Corporation'
  system.hardware.product = 'Latitude D800'
  system.hardware.version = ''
  system.chassis.manufacturer = 'Dell Computer Corporation'
  system.board.product = ''
  system.board.version = ''
  system.board.vendor = 'Dell Computer Corporation'
  system.chassis.type = 'Portable'
  system.formfactor = 'laptop'
  power_management.type = 'acpi'
  power_management.acpi.linux.version = '20100428'
  power_management.quirk.vbe_post = true
  power_management.quirk.vbestate_restore = true
  info.addons = { 'hald-addon-cpufreq', 'hald-addon-acpi' }
  org.freedesktop.Hal.Device.SystemPowerManagement.method_names = { 'Suspend', 'SuspendHybrid', 'Hibernate', 'Shutdown
', 'Reboot', 'SetPowerSave' }
  org.freedesktop.Hal.Device.SystemPowerManagement.method_signatures = { 'i', 'i', '', '', '', 'b' }
  org.freedesktop.Hal.Device.SystemPowerManagement.method_argnames = { 'num_seconds_to_sleep', 'num_seconds_to_sleep',
 '', '', '', 'enable_power_save' }
  org.freedesktop.Hal.Device.SystemPowerManagement.method_execpaths = { 'hal-system-power-suspend', 'hal-system-power-
suspend-hybrid', 'hal-system-power-hibernate', 'hal-system-power-shutdown', 'hal-system-power-reboot', 'hal-system-pow
er-set-power-save' }
  power_management.is_powersave_set = false
  info.callouts.add = { 'hal-storage-cleanup-all-mountpoints' }
[...]

root@johnn-craylap:~# hwinfo --gfxcard
20: PCI(AGP) 100.0: 0300 VGA compatible controller (VGA)
  [Created at pci.318]
  UDI: /org/freedesktop/Hal/devices/pci_10de_286
  Unique ID: VCu0.8ENJQHz3VVF
  Parent ID: vSkL.1o+Z33xgwU4
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "nVidia GeForce4 4200 Go"
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x0286 "GeForce4 4200 Go"
  SubVendor: pci 0x1028 "Dell"
  SubDevice: pci 0x0179
  Revision: 0xa1
  Driver: "nouveau"
  Driver Modules: "drm"
  Memory Range: 0xfc000000-0xfcffffff (rw,non-prefetchable)
  Memory Range: 0xf0000000-0xf3ffffff (ro,non-prefetchable)
  Memory Range: 0xfd000000-0xfd01ffff (ro,non-prefetchable,disabled)
  IRQ: 11 (15372 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v000010DEd00000286sv00001028sd00000179bc03sc00i00"
  Driver Info #0:
    XFree86 v4 Server Module: nv
  Driver Info #1:
    XFree86 v4 Server Module: nvidia
    3D Support: yes
    Color Depths: 16
    Extensions:
    Options:
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #10 (PCI bridge)
Primary display adapter: #20
root@johnn-craylap:~#

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: xserver-xorg-video-nouveau 1:0.0.16+git20100805+b96170a-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
Architecture: i386
DRM.card0.DVI.D.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.LVDS.1:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1920x1200 1920x1200 1920x1080 1600x1200 1680x1050 1400x1050 1280x1024 1280x960 1152x864 1024x768 800x600 640x480 720x400 640x400 640x350
 edid-base64: AP///////wAwZABQODczOSoNAQOAIRV4Ck/VnFdLjCcfUFQAAAABAQEBAQEBAQEBAQEBAQEBLz+ACHGwI0BkICYAS88QAAAYAAAADwAIKBA4ARECER4gCBIAAAAA/gA4VDc0OaExNTRFWjAKAAAA/gDfuaWTdlcoAAIACiAgADE=
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
Date: Sat Oct 2 11:17:25 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate i386 (20100928.1)
MachineType: Dell Computer Corporation Latitude D800
PccardctlIdent:
 Socket 0:
   no product info available
 Socket 1:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
 Socket 1:
   no card
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-22-generic root=/dev/mapper/80gblaphdd-rootvol ro splash
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: xserver-xorg-video-nouveau
dmi.bios.date: 06/30/2005
dmi.bios.vendor: Dell Computer Corporation
dmi.bios.version: A13
dmi.board.vendor: Dell Computer Corporation
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Computer Corporation
dmi.modalias: dmi:bvnDellComputerCorporation:bvrA13:bd06/30/2005:svnDellComputerCorporation:pnLatitudeD800:pvr:rvnDellComputerCorporation:rn:rvr:cvnDellComputerCorporation:ct8:cvr:
dmi.product.name: Latitude D800
dmi.sys.vendor: Dell Computer Corporation
system:
 distro: Ubuntu
 codename: maverick
 architecture: i686
 kernel: 2.6.35-22-generic

[John N (john-navitsky)]

I re-installed 10.04 on a different disk, and found that a fresh install used the nouveau driver as well and that it too exhibited the screen garbage problem. However, with 10.04, selecting "hardware drivers" offers the Nvidia accelerated graphics driver (version 96), which, once activated, works correctly with no garbage.

So, the following driver works OK:

johnn@johnn-laptop:~$ lsmod | grep -i nv
nvidia 4701243 32
agpgart 31724 2 nvidia,intel_agp
johnn@johnn-laptop:~$
johnn@johnn-laptop:~$ dpkg --get-selections | grep -i nvidia
nvidia-173-modaliases install
nvidia-96 install
nvidia-96-modaliases install
nvidia-common install
nvidia-current-modaliases install
nvidia-settings install
johnn@johnn-laptop:~$ dpkg --status nvidia-96
Package: nvidia-96
Status: install ok installed
Priority: optional
Section: restricted/misc
Installed-Size: 21868
Maintainer: Ubuntu Core Developers <email address hidden>
Architecture: i386
Source: nvidia-graphics-drivers-96
Version: 96.43.17-0ubuntu1
Provides: xserver-xorg-video-6
Depends: x11-common (>= 1:7.0.0), make, sed (>> 3.0), dkms, linux-libc-dev, libc6-dev, linux-headers-generic | linux-headers, patch, acpid, libc6 (>= 2.1), libx11-6 (>= 0), libxext6 (>= 0)
Recommends: nvidia-settings
Description: NVIDIA binary Xorg driver, kernel module and VDPAU library
 The binary driver provide optimized hardware acceleration of OpenGL
 applications via a direct-rendering X Server. AGP, PCIe, SLI, TV-out
 and flat panel displays are also supported.
 .
 This package also includes the source for building the kernel module
 required by the Xorg driver.
 .
 GPUs ranging from GeForce series 2 (except for GeForce2 GTS/GeForce2 Pro,
 GeForce2 Ti and GeForce2 Ultra) to Geforce series 7 are supported.
 .
 See /usr/share/doc/nvidia-96/README.txt.gz for a complete list
 of supported GPUs and PCIIDs
johnn@johnn-laptop:~$

And the following drivers DO NOT work correctly on this hardware:

johnn@johnn-laptop:~$ dpkg --get-selections | grep -i nouv
libdrm-nouveau1 install
xserver-xorg-video-nouveau install
johnn@johnn-laptop:~$ dpkg --status xserver-xorg-video-nouveau
Package: xserver-xorg-video-nouveau
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 272
Maintainer: Ubuntu MOTU Developers <email address hidden>
Architecture: i386
Version: 1:0.0.15+git20100219+9b4118d-0ubuntu5
Replaces: xserver-xorg (<< 6.8.2-35)
Provides: xserver-xorg-video-6
Depends: libc6 (>= 2.4), libdrm-nouveau1 (>= 2.4.16), xserver-xorg-core (>= 2:1.6.99.900)
Description: X.Org X server -- Nouveau display driver (experimental)
 This driver for the X.Org X server (see xserver-xorg for a further description)
 provides support for NVIDIA Riva, TNT, GeForce, and Quadro cards.
 .
 Although the nouveau project aims to provide full 3D support it is not yet
 complete, and these packages do not include any 3D support.
 Users requiring 3D support should use the non-free "nvidia" driver.
 .
 This package is built from the FreeDesktop.org xf86-video-nouveau driver.
Homepage: http://nouveau.freedesktop.org/wiki/
Original-Maintainer: Debian X Strike Force <debi...

[John N (john-navitsky)]

As a workaround, I was able to get the nvidia-96 drivers working, but it isn't quite seamless. First, I removed all nvidia packages that were currently installed (with --purge), then selected and installed the nvidia-96 drivers by searching "nvidia" within the "Ubuntu Software Center" and selecting "nvidia-96".

At this point the display would not start with the xorg.conf generated by the "nvidia-xconfig" utility. If you tried to start X with this xorg.conf file, you'd get a complaint that it couldn't find the nvidia driver.

Without an xorg.conf file, X would start, but set to a lower resolution with no ability to switch to 1920x1200.

At some point, I wondered if the nouveau driver was conflicting. I removed the xserver-xorg-video-nouveau package (again with --purge) and then (with no xorg.conf file) the nvidia 96 driver started working correctly with full resolution.

So the working config is:

johnn@johnn-craylap:~$ dpkg --get-selections | grep -i nvidia
nvidia-96 install
nvidia-glx-96 install
nvidia-settings install
johnn@johnn-craylap:~$ dpkg --get-selections | grep -i nouve
libdrm-nouveau1 install
johnn@johnn-craylap:~$ ls -al /etc/X11/xorg.conf
ls: cannot access /etc/X11/xorg.conf: No such file or directory
johnn@johnn-craylap:~$

[Yann Simon (yann-simon-fr)]

Bug description on Debian: http://lists.debian.org/debian-x/2010/09/msg00047.html

[Yann Simon (yann-simon-fr)]

booting with parameter "nomodeset" fixed the display problem, but the resolution is maximal 1280x1024.
Is is not a real solution.

[Michel (degreef-michel)]

I have exactly the same problem as the original poster, also with a D800 and wuxga 1920x1200

If it helps, I have noticed that sometimes my screen shows correctly (the graphics are fine and so is the cursor), perhaps when I log back on after the screensaver kicked in.

So it seems to me that everything needed to render correctly is likely installed.

Still, it is damn annoying not to have even a workaround and regretfully it is a show stopper for me.

[Michael Hufnagel (mhufnagel)]

I would like to support the request that this bug shall be fixed.

[John N (john-navitsky)]

In comment #6, Michel wrote:

"Still, it is damn annoying not to have even a workaround and regretfully it is a show stopper for me."

Does the workaround noted in comment #3 not work correctly for you? I recently did a fresh install and captured the steps more specificially when starting from a fresh install:

# List which nvidia modules are moved and remove all but the "-96" versions.

root@ubuntu-usb:~# dpkg --get-selections | grep -i nvidia
nvidia-173-modaliases install
nvidia-96 install
nvidia-96-modaliases install
nvidia-common install
nvidia-current-modaliases install
nvidia-settings install
root@ubuntu-usb:~# apt-get remove --purge nvidia-173-modaliases
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  nvidia-173-modaliases* nvidia-common*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 270kB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 144298 files and directories currently installed.)
Removing nvidia-common ...
Purging configuration files for nvidia-common ...
Removing nvidia-173-modaliases ...
root@ubuntu-usb:~#

Remove xserver-xorg-video-nouveau:

root@ubuntu-usb:~# dpkg --get-selections | grep -i nouve
libdrm-nouveau1 install
xserver-xorg-video-nouveau install
root@ubuntu-usb:~# apt-get remove --purge xserver-xorg-video-nouveau
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  xserver-xorg-video-all* xserver-xorg-video-nouveau*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 315kB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 144271 files and directories currently installed.)
Removing xserver-xorg-video-all ...
Removing xserver-xorg-video-nouveau ...
Processing triggers for man-db ...
root@ubuntu-usb:~#

Now, run the Ubuntu Software Center and search for "nvidia" using the search box. Select and install the item labeled "NVidia binary X.Org driver ('version 96' driver)".

Afterwards, this is what I have:

johnn@ubuntu-usb:~$ dpkg --get-selections | grep -i nvidia
nvidia-96 install
nvidia-96-modaliases install
nvidia-current-modaliases install
nvidia-glx-96 install
nvidia-settings install
johnn@ubuntu-usb:~$ dpkg --get-selections | grep -i nouveau
libdrm-nouveau1 install
johnn@ubuntu-usb:~$

Reboot the system. With a bit of luck, you'll now have full functionality using the Nvidia 96 driver.

-john

[John N (john-navitsky)]

I was messing with a different disk today and I noticed the most current nvidia driver works in addition to the -96 driver.

I deleted all the loaded nvidia packages, then deleted the nouveau package, then with the gui tool installed the nvidea-185 package and then rebooted.

It shows I have the following packages installed:

nvidia-current
nvidia-glx-185
nvidia-settings

-john

[John N (john-navitsky)]

Note the workarounds appear _not_ to work with Natty.

I upgraded and couldn't convince Natty to install -96 fully. I don't recall the exact message, but I think it suggested it couldn't satisfy the package dependencies.

When I install 185 as in comment #9, the driver doesn't appear to recognize the hardware.

root@johnn-craylap:~# cd /lib/modules/`uname -r`
root@johnn-craylap:/lib/modules/2.6.38-8-generic# find . -iname "nv*" -print
./kernel/drivers/char/nvram.ko
./kernel/drivers/video/nvidia
./kernel/drivers/video/nvidia/nvidiafb.ko
./kernel/drivers/watchdog/nv_tco.ko
./updates/dkms/nvidia-current.ko
root@johnn-craylap:/lib/modules/2.6.38-8-generic#

root@johnn-craylap:/lib/modules/2.6.38-8-generic# insmod updates/dkms/nvidia-current.ko
insmod: error inserting 'updates/dkms/nvidia-current.ko': -1 No such device
root@johnn-craylap:/lib/modules/2.6.38-8-generic#

root@johnn-craylap:/lib/modules/2.6.38-8-generic# dpkg --get-selections | grep -i nv
libgnome2-canvas-perl install
libgnomecanvas2-0 install
libgnomecanvas2-common install
libgoocanvas-common install
libgoocanvas3 install
libtext-iconv-perl install
nvidia-current install
nvidia-glx-185 install
nvidia-settings install
python-gnomecanvas install
python-pygoocanvas install
python-uniconvertor install
xserver-xorg-video-nv install
root@johnn-craylap:/lib/modules/2.6.38-8-generic#

[Ian Kumlien (pomac)]

This is odd, to get proper graphics, disable render.

To get a proper pointer, disable hwcursor.

If you disable both, the cursor is still broken

[Glenn Brumfield (brumfield-glenn)]

Nouveau has not supported the NV28 video cards since Ubuntu 8.10 was issued (8.04 worked perfectly). In my case I have an nVidia Geforce4 4200 [NV28] factory-OEM installed in a Dell Latitude D800 notebook. There is no replacement video card for this notebook that I am aware of and replacement would be uneconomical in any case. Since it appears that nVidia is on the verge of dropping support for the video cards requiring the nvidia-96 driver, it would seem that nouveau will be the only option in short order. Currently, the nvidia-96 driver is ABI incompatible with Ubuntu 12.04, which requires a rollback to the xorg server-xorg version from Oneiric to get the video card to run.

My symptoms under nouveau are that the cursor/pointer is garbled to the point of unusability. The desktop itself is clear but with occasional glitches; without a proper pointer, the GUI cannot be accurately utilized.

[R-ductor (r-ductor)]

Created attachment 66889
dmesg output

In a newly installed debian wheezy (no non-free nvidia drivers around) nouveau gives distorted graphics with a Geforce 4200Go (Dell inspiron 8500), see png attached. The mouse pointer is distorted and the desktop difficultly usable.

This bug has been reported in debian
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686611
and might be related to
https://bugs.freedesktop.org/show_bug.cgi?id=50403

The files I attach refer to

# cat /etc/X11/xorg.conf.d/98-me
Section "Device"
Identifier "Device0"
Driver "nouveau"
EndSection

and no other tricks, but I've also tried:

1) boot with nouveau.noaccel=1 in kernel line
   TTY and X badly screwed up

2) boot with nouveau.nofbaccel=1 in kernel line
   TTY badly screwed up, X distorted as in the plain case

3) boot with Option "NoAccel" "On"
X distorted

4) Booted with experimenta kernel
linux-image-3.5-trunk-686-pae
Version: 3.5.2-1~experimental.1
black TTY and black X so I cannot document this.

-----Kernel version
# cat /proc/version
Linux version 3.2.0-3-686-pae (Debian 3.2.23-1) (<email address hidden>) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Mon Jul 23 03:50:34 UTC 2012

-----Nouveau version
# aptitude show xserver-xorg-video-nouveau
Package: xserver-xorg-video-nouveau
State: installed
Automatically installed: yes
Version: 1:1.0.1-3
Priority: optional
Section: x11
Maintainer: Debian X Strike Force <email address hidden>
Architecture: i386
Uncompressed Size: 483 k
Depends: libc6 (>= 2.4), libdrm2 (>= 2.4.17), libudev0 (>= 146), xorg-video-abi-12, xserver-xorg-core (>= 2:1.11.99.901)
Recommends: libgl1-mesa-dri (>= 7.11.1)
Provides: xorg-driver-video
Description: X.Org X server -- Nouveau display driver
 This driver for the X.Org X server (see xserver-xorg for a further description) provides support for NVIDIA Riva, TNT,
 GeForce, and Quadro cards.

 This package provides 2D support including EXA acceleration, Xv and RandR. 3D functionality is provided by the
 libgl1-mesa-dri package.

 This package is built from the FreeDesktop.org xf86-video-nouveau driver.
Homepage: http://nouveau.freedesktop.org/wiki/

[R-ductor (r-ductor)]

Created attachment 66890
dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64

[R-ductor (r-ductor)]

Created attachment 66892
Xorg.0.log

[Bib (bybeu)]

nvdia just released a new driver: see https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/948053 post #119

[R-ductor (r-ductor)]

UPDATE: same problem with newer versions (yesterday's debian testing releases)

# uname -a
Linux majorana 3.9-1-686-pae #1 SMP Debian 3.9.6-1 i686 GNU/Linux

# aptitude show xserver-xorg-video-nouveau
Package: xserver-xorg-video-nouveau
State: installed
Automatically installed: yes
Version: 1:1.0.8-1
Priority: optional
Section: x11
Maintainer: Debian X Strike Force <email address hidden>
Architecture: i386
Uncompressed Size: 479 k
Depends: libc6 (>= 2.15), libdrm-nouveau2 (>= 2.4.34), libdrm2 (>= 2.4.17), libudev0 (>= 146), xorg-video-abi-12,
         xserver-xorg-core (>= 2:1.12.3.901)
Recommends: libgl1-mesa-dri (>= 7.11.1)
Provides: xorg-driver-video
Description: X.Org X server -- Nouveau display driver
 This driver for the X.Org X server (see xserver-xorg for a further description) provides support for NVIDIA Riva, TNT,
 GeForce, and Quadro cards.

# lsmod|egrep 'fb|nv'
# lsmod|egrep 'nouveau'
nouveau 631975 2
mxm_wmi 12467 1 nouveau
wmi 13051 2 mxm_wmi,nouveau
ttm 52594 1 nouveau
drm_kms_helper 27237 2 ch7006,nouveau
drm 165971 5 ttm,drm_kms_helper,ch7006,nouveau
i2c_algo_bit 12713 1 nouveau
i2c_core 19248 5 drm,drm_kms_helper,i2c_algo_bit,ch7006,nouveau
video 17462 1 nouveau
button 12824 1 nouveau
#

# ls /etc/X11/xorg.conf
ls: cannot access /etc/X11/xorg.conf: No such file or directory
# ls /etc/X11/xorg.conf.d
modesetting.conf-off nouveau.conf
# cat /etc/X11/xorg.conf.d/nouveau.conf
Section "Device"
Identifier "Device0"
Driver "nouveau"
EndSection

# cat /boot/config-`uname -r`|egrep 'FRAMEBUFFER'
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y

# cat /boot/config-`uname -r`|egrep 'HW_CONSOLE_BINDING'
CONFIG_VT_HW_CONSOLE_BINDING=y

# cat /proc/fb
0 nouveaufb

MORE INFO TO BE ATTACHED.

[R-ductor (r-ductor)]

Created attachment 82135
output of dmesg 2013-07-06

[R-ductor (r-ductor)]

Created attachment 82136
Xorg.0.log v2013-07-06

[R-ductor (r-ductor)]

Created attachment 82138
dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64 #2013-07-06

[R-ductor (r-ductor)]

Created attachment 82139
output of lsmod (2013-07-06)

[R-ductor (r-ductor)]

Created attachment 82140
output of sysctl --all (2013-07-06)

[R-ductor (r-ductor)]

.... further info ....

# xrandr --verbose --q12
No protocol specified
Can't open display :0
# xrandr --prop --q12
No protocol specified
Can't open display :0

The only anomaly in Xorg.0.log I can detect is:
[ 26.386] (II) NOUVEAU(0): Unknown vendor-specific block f
[ 26.386] (II) NOUVEAU(0): U0674^B<9A>M1LW02
[ 26.386] (II) NOUVEAU(0): <C0><B0><A0><90><80>hH
[ 26.386] (II) NOUVEAU(0): EDID (in hex):
[ 26.386] (II) NOUVEAU(0): 00ffffffffffff004d109f1300000000
[ 26.386] (II) NOUVEAU(0): 200d0103802115780aa8a098554d8f26
[ 26.386] (II) NOUVEAU(0): 1f505400000001010101010101010101
[ 26.386] (II) NOUVEAU(0): 0101010101012f3f800871b023406420
[ 26.386] (II) NOUVEAU(0): 26004bcf100000190000000f00000000
[ 26.386] (II) NOUVEAU(0): 00000000002892025000000000fe0055
[ 26.386] (II) NOUVEAU(0): 30363734029a4d314c573032000000fe
[ 26.386] (II) NOUVEAU(0): 00c0b0a0908068480002010a202000a4

# dmesg|egrep -C 2 'nouveau E'
[ 7.842891] nouveau [ DRM] DCB outp 00: 01000100 000088b8
[ 7.842900] nouveau [ DRM] DCB outp 01: 02110223 00000064
[ 7.842907] nouveau E[ DRM] Unknown LVDS configuration bits, please report
[ 7.842985] nouveau [ DRM] DCB outp 02: 01120312 00000040
[ 7.842994] nouveau [ DRM] DCB outp 03: 01130321 00000001

... I'll be happy to report more info if required (in a detailed way please)

[R-ductor (r-ductor)]

... xrandr as seen from user account (forget the previous ones taken from root) ...

$ xrandr --verbose
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 4096 x 4096
VGA-1 disconnected (normal left inverted right x axis y axis)
        Identifier: 0x51
        Timestamp: 24877
        Subpixel: unknown
        Clones:
        CRTCs: 0
        Transform: 1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter:
LVDS-1 connected 1920x1200+0+0 (0x54) normal (normal left inverted right x axis y axis) 331mm x 207mm
        Identifier: 0x52
        Timestamp: 24877
        Subpixel: unknown
        Gamma: 1.0:1.0:1.0
        Brightness: 1.0
        Clones:
        CRTC: 1
        CRTCs: 1
        Transform: 1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter:
        EDID:
                00ffffffffffff004d109f1300000000
                200d0103802115780aa8a098554d8f26
                1f505400000001010101010101010101
                0101010101012f3f800871b023406420
                26004bcf100000190000000f00000000
                00000000002892025000000000fe0055
                30363734029a4d314c573032000000fe
                00c0b0a0908068480002010a202000a4
        scale: 1 (0x00000001) range: (0,2)
        flicker reduction: 50 (0x00000032) range: (0,100)
        contrast: 50 (0x00000032) range: (0,100)
        brightness: 50 (0x00000032) range: (0,100)
        mode: PAL
                supported: PAL ...

[Emil-l-velikov (emil-l-velikov)]

Several interesting points

* Does the corruption/distored graphics occur before X ?

* Wondering how much effect this has "Unknown LVDS configuration bits"
Does that issue occur on a non LVDS output - eg. when you have monitor plugged to the VGA and LVDS is off ?

* Does the "distorted graphics" differ if you (re)move the mesa driver nouveau_vieux.so ?

* Why do you have custom modelines in your xorg.conf? Have you tried with a plain (empty) xorg.conf ?

[R-ductor (r-ductor)]

Created attachment 82142
distorted graphics

I agree that distorted is not the good wording, but I do not how to qualify this misbeaviour.

Just to have an idea of what I mean by distorted graphics I upload a snapshot of the iceweasel log.

The mostdisturbing feature is the doubling of the cursor arrows (and each one is distorted as the logo), which makes the system hard to use.

[R-ductor (r-ductor)]

(In reply to comment #12)

Hello, I had just installed the nvidia proprietary driver :(((( when I saw the questions, so now I've unistalled everything just to answer ...

> * Does the corruption/distored graphics occur before X ?

framebuffer console seems ok. The anomalous graphics starts when loading kdm. See the picture above.

> * Wondering how much effect this has "Unknown LVDS configuration bits"
> Does that issue occur on a non LVDS output - eg. when you have monitor
> plugged to the VGA and LVDS is off ?

It's a laptop: how can I do that?

> * Does the "distorted graphics" differ if you (re)move the mesa driver
> nouveau_vieux.so ?

YES, just reproduced after
  mv /usr/lib/i386-linux-gnu/dri/{,__unloaded__}nouveau_vieux_dri.so

> * Why do you have custom modelines in your xorg.conf?

Do not know. I do not have a xorg.conf, nor I did not modified anything apart the conf files in xorg, which are currently disabled by the -off suffix (by they are trivial, anyway, see below)

root@majorana:~# ls /etc/X11
app-defaults default-display-manager rgb.txt xinit xorg.conf.d Xreset.d Xsession Xsession.options Xwrapper.config
cursors fonts X xkb Xreset Xresources Xsession.d XvMCConfig

root@majorana:~# ls /etc/X11/xorg.conf.d/
modesetting.conf-off nouveau.conf-off nvidia.conf-off vesa.conf-off

root@majorana:~# cat /etc/X11/xorg.conf.d/*
Section "Device"
Identifier "Device0"
Driver "modesetting"
BusID "pci:0000:01:00.0"
EndSection

Section "Device"
Identifier "Device0"
Driver "nouveau"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
EndSection

Section "Device"
Identifier "Device0"
Driver "vesa"
EndSection

[R-ductor (r-ductor)]

Created attachment 82146
dmesg with nvidia driver (2013-07-06)

[R-ductor (r-ductor)]

Created attachment 82147
Xorg.0.log with nvidia driver

[R-ductor (r-ductor)]

... further info ...

I've attached dmesg and Xorg.0.log obtained when the nvidia driver 96.43.23 was running (and everything seemed fine)

[R-ductor (r-ductor)]

(In reply to comment #12)
> Have you tried with a plain (empty) xorg.conf ?

# cat /etc/X11/xorg.conf
#

Done, same misbehavior.

[Emil-l-velikov (emil-l-velikov)]

(In reply to comment #13)
> Created attachment 82142 [details]
> distorted graphics
>
> I agree that distorted is not the good wording, but I do not how to qualify
> this misbeaviour.
>
> Just to have an idea of what I mean by distorted graphics I upload a
> snapshot of the iceweasel log.
>
> The mostdisturbing feature is the doubling of the cursor arrows (and each
> one is distorted as the logo), which makes the system hard to use.

Looks like every other column is shifted to the right by x*2. I'll see if I can get the number of X, unless you beat me to it :)

To be on the safe side, use the left mouse cursor :P

[Emil-l-velikov (emil-l-velikov)]

(In reply to comment #14)
> (In reply to comment #12)
...
> > * Wondering how much effect this has "Unknown LVDS configuration bits"
> > Does that issue occur on a non LVDS output - eg. when you have monitor
> > plugged to the VGA and LVDS is off ?
>
> It's a laptop: how can I do that?
>
1. Connect in a monitor/TV to the VGA(DVI-D) connector
2. Set it up - use xrandr or your favourite gui app
(replace the VGA-1 with DVI-D-1 if appropriate)
$ xrandr --output VGA-1 --auto

3. Disable LVDS - use xrandr or your favourite gui app
$ xrandr --output LVDS-1 --off

> > * Does the "distorted graphics" differ if you (re)move the mesa driver
> > nouveau_vieux.so ?
>
> YES, just reproduced after
> mv /usr/lib/i386-linux-gnu/dri/{,__unloaded__}nouveau_vieux_dri.so
>
Did you restart X after doing that ?

> > * Why do you have custom modelines in your xorg.conf?
>
> Do not know. I do not have a xorg.conf, nor I did not modified anything
> apart the conf files in xorg, which are currently disabled by the -off
> suffix (by they are trivial, anyway, see below)
>
Got distracted there, my bad

[Ilia Mirkin (imirkin)]

From the screenshot, it looks like a tiling mode is being misset. I saw something similar with a thing I was implementing on NV96, I forgot to set tiling mode 0x20 (which is tiling Y = 2), and saw a very similar effect, but with lines being horizontal. Not sure if memory worked the same on NV28, but thought I'd mention it.

[R-ductor (r-ductor)]

(In reply to comment #20)
> (In reply to comment #14)
> > (In reply to comment #12)

> > > * Does the "distorted graphics" differ if you (re)move the mesa driver
> > > nouveau_vieux.so ?
> >
> > YES, just reproduced after
> > mv /usr/lib/i386-linux-gnu/dri/{,__unloaded__}nouveau_vieux_dri.so
> >
> Did you restart X after doing that ?

Yes, I've rebooted after the move.

[R-ductor (r-ductor)]

(In reply to comment #20)
> (In reply to comment #14)
> > (In reply to comment #12)
> ...
> > > * Wondering how much effect this has "Unknown LVDS configuration bits"
> > > Does that issue occur on a non LVDS output - eg. when you have monitor
> > > plugged to the VGA and LVDS is off ?
> >
> > It's a laptop: how can I do that?
> >
> 1. Connect in a monitor/TV to the VGA(DVI-D) connector
> 2. Set it up - use xrandr or your favourite gui app
> (replace the VGA-1 with DVI-D-1 if appropriate)
> $ xrandr --output VGA-1 --auto
>
> 3. Disable LVDS - use xrandr or your favourite gui app
> $ xrandr --output LVDS-1 --off

Test done (with VGA, check xrandr attached), with same anomalies on external monitor (see attachment). Just in case I attach also dmesg and Xorg.log when booting with external monitor connected.

[R-ductor (r-ductor)]

Created attachment 82378
Photo of external vga monitor. Distorted iceweasel logo and double coursor.

[R-ductor (r-ductor)]

Created attachment 82379
xrandr log of test with external VGA monitor

[R-ductor (r-ductor)]

Created attachment 82380
dmesg when booting with external VGA monitor

[R-ductor (r-ductor)]

Created attachment 82381
Xorg.log when booting with external VGA monitor

[R-ductor (r-ductor)]

Created attachment 82382
Photo of external vga monitor. Distorted iceweasel logo and double coursor.

[R-ductor (r-ductor)]

For comparison I add some info when the nvidia legacy driver is used: xrandr output, dmesg, Xorg.0.log

[R-ductor (r-ductor)]

Created attachment 82386
xrandr with nvidia legacy

[R-ductor (r-ductor)]

Created attachment 82387
xorg.log with nvidia legacy

[R-ductor (r-ductor)]

Created attachment 82388
dmesg with nvidia legagcy

[Emil-l-velikov (emil-l-velikov)]

Unfortunately the blob (proprietary driver) does not provide any useful information in these logs.

As mentioned it seems like the tiling (pitch) is misset by ~64 (after a quick look at the attached picture)

Can you do try and establish if the issue happens in or outside of X, and in which cases - i.e. in X only when drawing an image of dimensions x1 & y1, or less than x2 & greater than y2

Meanwhile I'll prep some debug patches (note you may need to rebuild xf86-video-nouveau, libdrm and/or nouveau) :)

[R-ductor (r-ductor)]

Hi Emil (just for you because not really intersting for the bucg tracker)

I can try what you ask this week end (than I will be on vacation for 15 days without internet).

Some questions

> As mentioned it seems like the tiling (pitch) is misset by ~64 (after a quick
> look at the attached picture)

I'll look around for a doc to understand what you're saying...

> Can you do try and establish if the issue happens in or outside of X, and in
> which cases

what do you mean by outside X? Framebuffer terminal seemed ok, how can I show a graphic without X?

>i.e. in X only when drawing an image of dimensions x1 & y1, or
> less than x2 & greater than y2

You mean rescaling a single image or showing images of different pixel size?

And you really mean drawing (e.g. with office draw) or just showing existing images?

> Meanwhile I'll prep some debug patches (note you may need to rebuild
> xf86-video-nouveau, libdrm and/or nouveau) :)

Just explain me what to do and I'll do it, I'm happy to help.

Cheers
ric

On 2013-07-24 02:55:04 <email address hidden> wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=54700
>
> --- Comment #33 from Emil Velikov <email address hidden> ---
> Unfortunately the blob (proprietary driver) does not provide any useful
> information in these logs.
>
> As mentioned it seems like the tiling (pitch) is misset by ~64 (after a quick
> look at the attached picture)
>
> Can you do try and establish if the issue happens in or outside of X, and in
> which cases - i.e. in X only when drawing an image of dimensions x1 & y1, or
> less than x2 & greater than y2
>
> Meanwhile I'll prep some debug patches (note you may need to rebuild
> xf86-video-nouveau, libdrm and/or nouveau) :)
>
>

[Emil-l-velikov (emil-l-velikov)]

(In reply to comment #34)
> > As mentioned it seems like the tiling (pitch) is misset by ~64 (after a quick
> > look at the attached picture)
>
> I'll look around for a doc to understand what you're saying...
>
My knowledge is kinf of flacky in the area, so here is the way I understand it.
Gpus do not always treat and/or use memory on a linear way. It may be handled as a tile with certain dimensions

> > Can you do try and establish if the issue happens in or outside of X, and in
> > which cases
>
> what do you mean by outside X? Framebuffer terminal seemed ok, how can I
> show a graphic without X?
>
Yes I meant the framebuffer. Not sure of many ways to draw stuff on it - directFB is project that normally deals with such things [1]. My main point is to understand if the issue is xf86-video-nouveau or libdrm/kernel related

> >i.e. in X only when drawing an image of dimensions x1 & y1, or
> > less than x2 & greater than y2
>
> You mean rescaling a single image or showing images of different pixel size?
>
> And you really mean drawing (e.g. with office draw) or just showing existing
> images?
>
I meant rendering images of different sizes. Looking at the iceweasel.png at bugs.debian.org indicates not everything rendered exhibits the distortion - would be great to know something specific about the files causing it

Simple tests
* grab the ice weasel picture, open it in a image viewer (and/or browser) - distorted ?
* rescale the image (using gimp or other software), reopen the picture and observe.
* same for the cursor file

Cheers
Emil

[1] http://www.directfb.org/docs/DirectFB_Tutorials/image.html

[R-ductor (r-ductor)]

Created attachment 83141
fractal_97_1862x1048 not rescaled by iceweasel

[R-ductor (r-ductor)]

Created attachment 83142
fractal_97_1862x1048 not rescaled by iceweasel

[R-ductor (r-ductor)]

Created attachment 83143
fractal_97_1862x1048 not rescaled by iceweasel

[R-ductor (r-ductor)]

Created attachment 83144
fractal_97_1862x1048 ***rescaled*** by iceweasel

converted to jpg by gimp to decrease the size

[R-ductor (r-ductor)]

Created attachment 83145
fractal_97_1862x1048 ***rescaled*** by iceweasel

[R-ductor (r-ductor)]

Created attachment 83146
fractal2 recaled and not rescaled by iceweasel

[R-ductor (r-ductor)]

Created attachment 83147
dmesg after nouveau/GPU crash

[R-ductor (r-ductor)]

Created attachment 83148
links2 -g &> output (graphics in framebuffer)

[R-ductor (r-ductor)]

Created attachment 83149
links -g rendered graphics in framebuffer

[R-ductor (r-ductor)]

Created attachment 83150
links2 framebuffer graphics: the same fractal

[R-ductor (r-ductor)]

Created attachment 83151
just another horrible view of my problem....

[R-ductor (r-ductor)]

Hi

1) I've downloaded an image of fractal and I've used this script

#!/bin/bash

BAN="fractal"
EXT="jpg"

for i in {001..100};do
/usr/bin/convert "${BAN}.${EXT}" -resize "${i}%" -set filename:wh "%wx%h" "${BAN}_${i}_%[filename:wh].${EXT}"
done

to create 100 samples
$ ls
fractal_001_19x11.jpg fractal_011_211x119.jpg fractal_021_403x227.jpg fractal_031_595x335.jpg fractal_041_787x443.jpg fractal_051_979x551.jpg fractal_061_1171x659.jpg fractal_071_1363x767.jpg fractal_081_1555x875.jpg fractal_091_1747x983.jpg fractal.jpg
fractal_002_38x22.jpg fractal_012_230x130.jpg fractal_022_422x238.jpg fractal_032_614x346.jpg fractal_042_806x454.jpg fractal_052_998x562.jpg fractal_062_1190x670.jpg fractal_072_1382x778.jpg fractal_082_1574x886.jpg fractal_092_1766x994.jpg
fractal_003_58x32.jpg fractal_013_250x140.jpg fractal_023_442x248.jpg fractal_033_634x356.jpg fractal_043_826x464.jpg fractal_053_1018x572.jpg fractal_063_1210x680.jpg fractal_073_1402x788.jpg fractal_083_1594x896.jpg fractal_093_1786x1004.jpg
fractal_004_77x43.jpg fractal_014_269x151.jpg fractal_024_461x259.jpg fractal_034_653x367.jpg fractal_044_845x475.jpg fractal_054_1037x583.jpg fractal_064_1229x691.jpg fractal_074_1421x799.jpg fractal_084_1613x907.jpg fractal_094_1805x1015.jpg
fractal_005_96x54.jpg fractal_015_288x162.jpg fractal_025_480x270.jpg fractal_035_672x378.jpg fractal_045_864x486.jpg fractal_055_1056x594.jpg fractal_065_1248x702.jpg fractal_075_1440x810.jpg fractal_085_1632x918.jpg fractal_095_1824x1026.jpg
fractal_006_115x65.jpg fractal_016_307x173.jpg fractal_026_499x281.jpg fractal_036_691x389.jpg fractal_046_883x497.jpg fractal_056_1075x605.jpg fractal_066_1267x713.jpg fractal_076_1459x821.jpg fractal_086_1651x929.jpg fractal_096_1843x1037.jpg
fractal_007_134x76.jpg fractal_017_326x184.jpg fractal_027_518x292.jpg fractal_037_710x400.jpg fractal_047_902x508.jpg fractal_057_1094x616.jpg fractal_067_1286x724.jpg fractal_077_1478x832.jpg fractal_087_1670x940.jpg fractal_097_1862x1048.jpg
fractal_008_154x86.jpg fractal_018_346x194.jpg fractal_028_538x302.jpg fractal_038_730x410.jpg fractal_048_922x518.jpg fractal_058_1114x626.jpg fractal_068_1306x734.jpg fractal_078_1498x842.jpg fractal_088_1690x950.jpg fractal_098_1882x1058.jpg
fractal_009_173x97.jpg fractal_019_365x205.jpg fractal_029_557x313.jpg fractal_039_749x421.jpg fractal_049_941x529.jpg fractal_059_1133x637.jpg fractal_069_1325x745.jpg fractal_079_1517x853.jpg fractal_089_1709x961.jpg fractal_099_1901x1069.jpg
fractal_010_192x108.jpg fractal_020_384x216.jpg fractal_030_576x324.jpg fractal_040_768x432.jpg fractal_050_960x540.jpg fractal_060_1152x648.jpg fractal_070_1344x756.jpg fractal_080_1536x864.jpg fractal_090_1728x972.jpg fractal_100_1920x1080.jpg

I've do the same for fractal2, a different fractal (png)

2) opening the samples with iceweasel all gets well while the image is not rescaled by iceweasel: if the image is rescaled by iw then is rendered corrupted; if I enlarge the window (or zoom in) the image is rendered OK. See attachments fractal97 and fractal2..... I'm confused, I cannot find what Emil a...

[Emil-l-velikov (emil-l-velikov)]

Thanks this is enough on the image side.

So link2 (directfb) exhibits the same issue, although in X not everything is affected. Same dimension image can be rendered with and without corruption, next to each other :P Seems like on some instances nouveau_bo_new() is not given the correct params (and/or the kernel does not like them :)

A couple of tests

1. Startup X with SWCursor, by adding "Option "HWCursor" "O"" in your xorg.conf(see $man nouveau for more information)
Does the cursor render properly ?

2. Make sure nouveau_vieux_dri.so is available and confirm that you have 3d acceleration $ glxinfo | grep render
The above command should give you
* direct rendering: Yes
* OpenGL renderer string: Mesa DRI nv28 *****
Startup glxgears and adjust the window size and note when corruption does and does not occur

Example: @ 200x500 graphics are corrupted, at other sizes everything is fine (or vice-versa)

[R-ductor (r-ductor)]

(In reply to comment #48)
> 1. Startup X with SWCursor, by adding "Option "HWCursor" "O"" in your
> xorg.conf(see $man nouveau for more information)
> Does the cursor render properly ?

YES :)

> 2. Make sure nouveau_vieux_dri.so is available and confirm that you have 3d
> acceleration $ glxinfo | grep render
> The above command should give you
> * direct rendering: Yes
> * OpenGL renderer string: Mesa DRI nv28 *****
> Startup glxgears and adjust the window size and note when corruption does
> and does not occur

nouveau_vieux_dri.so OK

glxinfo OK

NO signs of corruption in glxgears from a tiny window to a full screen ... but resizing glxgears I had X freeze twice, see below

cheers
ric

root:/etc/X11/xorg.conf.d# cat nouveau.conf
Section "Device"
Identifier "Device0"
Driver "nouveau"
Option "HWCursor" "0"
EndSection

root:# ls /usr/lib/i386-linux-gnu/dri/nouveau_vieux_dri.so
/usr/lib/i386-linux-gnu/dri/nouveau_vieux_dri.so

$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI nv28 x86/MMX/SSE2

dmesg:
....
[ 29.568428] Bluetooth: RFCOMM socket layer initialized
[ 29.568438] Bluetooth: RFCOMM ver 1.11
[ 29.638047] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 29.638059] Bluetooth: BNEP filters: protocol multicast
[ 29.638087] Bluetooth: BNEP socket layer initialized
[ 29.816224] b44 ssb0:0 eth0: Link is up at 100 Mbps, full duplex
[ 29.816239] b44 ssb0:0 eth0: Flow control is off for TX and off for RX
[ 29.816324] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 31.339168] lp0: using parport0 (interrupt-driven).
[ 31.364755] ppdev: user-space parallel port driver
[ 501.620039] nouveau E[Xorg[2328]] reloc wait_idle failed: -16
[ 501.620056] nouveau E[Xorg[2328]] reloc apply: -16
[ 501.624016] [sched_delayed] sched: RT throttling activated
[ 504.628042] nouveau E[Xorg[2328]] reloc wait_idle failed: -16
[ 504.628057] nouveau E[Xorg[2328]] reloc apply: -16
[ 507.628030] nouveau E[Xorg[2328]] reloc wait_idle failed: -16
[ 507.628039] nouveau E[Xorg[2328]] reloc apply: -16
[ 511.028041] nouveau E[Xorg[2328]] reloc wait_idle failed: -16
[ 511.028057] nouveau E[Xorg[2328]] reloc apply: -16
[ 514.036040] nouveau E[Xorg[2328]] reloc wait_idle failed: -16
[ 514.036054] nouveau E[Xorg[2328]] reloc apply: -16
[ 517.040030] nouveau E[Xorg[2328]] reloc wait_idle failed: -16
[ 517.040040] nouveau E[Xorg[2328]] reloc apply: -16
[ 520.040028] nouveau E[Xorg[2328]] reloc wait_idle failed: -16
[ 520.040038] nouveau E[Xorg[2328]] reloc apply: -16
[ 523.044030] nouveau E[Xorg[2328]] reloc wait_idle failed: -16
[ 523.044039] nouveau E[Xorg[2328]] reloc apply: -16
[ 532.112094] nouveau [ DRM] Calling LVDS script 6: ...

[Emil-l-velikov (emil-l-velikov)]

(In reply to comment #49)
> (In reply to comment #48)
> > 1. Startup X with SWCursor, by adding "Option "HWCursor" "O"" in your
> > xorg.conf(see $man nouveau for more information)
> > Does the cursor render properly ?
>
> YES :)
>
So nouveau_bo_new() it is. Might be worth setting up an X session with nothing but a plain X, xterm and HWCursor.

> NO signs of corruption in glxgears from a tiny window to a full screen ...
> but resizing glxgears I had X freeze twice, see below
>
Bummer, older cards seems to me quite susceptible to those issues (reloc wait_idle failed: -16)

[Emil-l-velikov (emil-l-velikov)]

A few random thoughts

* is the cursor provided truly 64x64 ?

* from drmmode_load_cursor_argb(
struct nouveau_bo *cursor; cursor->map

Data seems to be linear, lacking any pitch/tile alignment. Does libdrm/kernel agree with us ?

* from drmmode_crtc_init()
flags - use NOUVEAU_BO_VRAM rather than BO_GART (ie. revert 912d418f)
flags - use NOUVEAU_BO_CONTIG ?
config - set surf_flags, surf_pitch ?

[Ilia Mirkin (imirkin)]

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

[Bib (bybeu)]

https://bugs.freedesktop.org/show_bug.cgi?id=54700

[Emgaron+freedesktop (emgaron+freedesktop)]

I just discovered this bug as I acquired a Dell Inspiron 8500 a few weeks back and ran into the same problem. In fact, on my machine (same nVidia graphics), the problem even seems worse: Any attempt at using the nouveau driver so far has not only produced the distortions described by the original poster, but also ended with a GPU lock-up after a few minutes maximum. For that reason, I'm now running Xubuntu 12.04 on that machine, as this distribution still provides the older nvidia-96 proprietary driver - newer distros apparently dropped this version. With the proprietary driver, the laptop runs fine and actually quite smooth (considering the age and specs). As it would be nice to be able to run newer Linux distros on this machine, I'd be happy to help with experimenting/testing. I could install a newer distro (and hence - presumably - newer nouveau driver) on a second hard drive or on an external drive so I can test stuff. Any preferences which distro would be most helpful for you?

[Bib (bybeu)]

I ended in Ubuntu 12.04 with latest nvidia-96(-updates maybe). The Laptop sleeps now for weeks and I won't wake it up. I Just can say that once I admitted that vino won't work with desktop effects, I decided to use this laptop with gnome-shell no-effects only, and with the latest drivers state above the laptop now can be used.

I'm not a coder so I can't help further and I see we are only two who subscribed this thread. My single company surely won't help you to go further, emgaron.

[penalvch (penalvch)]

John Navitsky, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-nouveau REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[John N (john-navitsky)]

I was not able to boot the referenced ISO as it appears even the i386 kernel requires PAE (seems like a bug?).

I will try to upgrade existing installed OS, but it will take a fair amount of time.

-john

[Nv28m (nv28m)]

I also have this problem. Everything unaccelerated comes up as trash, even on the kernel framebuffer (if acceleration was switched off). Or for example I can see most of the graphics ok, but if I use ShadowFB then the whole screen is unusable. And the cursor is garbage too most of the time.

This is nothing new, but I found a way to make it work.

I have two systems installed (latest debian/testing). I boot the first one to X with the nvidia drivers. Then I use kexec to boot into the second system (also debian/testing), which is using nouveau. And at this time, all the graphics are fine!

So something is initialized by the nvidia driver, which is not touched by nouveau but is required for correct operation.

Is there a way I could help? Like dumping register states with/without the nvidia init?

[Nv28m (nv28m)]

Doing a suspend to RAM restores the original trashing behaviour. I'm not sure, but maybe the screen update is slower as well now.

This is a Dell D800:
01:00.0 VGA compatible controller: NVIDIA Corporation NV28M [GeForce4 Ti 4200 Go AGP 8x] (rev a1)

X.Org X Server 1.15.1
Release Date: 2014-04-13
[ 263.867] X Protocol Version 11, Revision 0
[ 263.867] Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
[ 263.867] Current Operating System: Linux dell 3.13-1-686-pae #1 SMP Debian 3.13.7-1 (2014-03-25) i686
[ 263.867] Kernel command line: BOOT_IMAGE=/vmlinuz-3.13-1-686-pae-mine2 root=/dev/mapper/root ro processor.ignore_ppc=1 quiet
[ 263.867] Build Date: 15 April 2014 07:46:36PM
[ 263.867] xorg-server 2:1.15.1-1 (http://www.debian.org/support)
[ 263.873] (II) NOUVEAU driver Date: Thu Nov 7 14:56:48 2013 +1000

[Ilia Mirkin (imirkin)]

(In reply to comment #55)
> So something is initialized by the nvidia driver, which is not touched by
> nouveau but is required for correct operation.
>
> Is there a way I could help? Like dumping register states with/without the
> nvidia init?

You could do a mmiotrace of the nvidia driver. It's likely that we're missing some bit of init. The resulting file will probably be quite large (50-100MB)... xz -9 it and email to <email address hidden>. (Also wouldn't hurt to upload your vbios from /sys/kernel/debug/dri/0/vbios.rom to this bug, and also attach it in the email while you're at it.)

[Nv28m (nv28m)]

The default Debian kernel is not very debug friendly, so I've dumped the ROMs with nvagetbios. There are two versions, as I made a firmware update later to see if it helps. (e-mailed)

The MMIO dumps are comming soon, tomorrow or so. This is a slow machine and the kernel compile takes a while even after I've reduced the config file (and set CONFIG_MMIOTRACE).

[Nv28m (nv28m)]

I've e-mailed the dump file.

I've put in 3 markers, one before starting xinit /usr/bin/urxvt, one in urxvt before quiting, and one after xinit returned.

I hope it's useful. Thanks! I can try to repeat the same thing using the nouveau driver, if needed.

[Bib (bybeu)]

I ignore if it's related, but my Dell D800 with nv28 burts many-many-many beeps on boot until the grub menu displays. Feel free to ask any thing.
Regards

[Nv28m (nv28m)]

I had the feeling that there's not much chance that the dump alone will help. So I did some debugging on my own, after all it can't be that hard if I have the hardware at hand to play with ;)

First I've collected all writes locations out from the dump, and ignored the part which looked like a frame buffer. I got around 260 locations, I guess most of these must be mapped registers.

Then I did the nvidia boot and kexec to nouveau, when everything works except that the GPU locks after a while.

Anyway, it's stable enough to dump of those 260 registers. Then I made a suspend to RAM, and back. Screen trashing is back of course, but let's dump those registers again.

Comparing the dumps reveals that 30 locations are different now.

I wrote all those registers back as they were before the suspend. Of course console went immediately blank. But I can still start X blindly, which hangs of course, but at least I can move a flawless cursor around. (normally it's trashed as well)

So it must be one of these. I resorted to normal bisecting from here to find transhing/non-trashing set of registers. There were plenty of hangs and reboots ;)

At the end I got what I wanted. The winner is:
nvapoke 00100080 e1000000

This register is e0000000 after suspend or after clean boot. So all this trouble only because of a single bit was not set ;(

The earlier GPU lockup (with kexec nouveau after nvidia driver init) does not happen anymore when I only set this bit, but nothing else. It probably must be due to some other uninitialized state, but I'm not sure if it's worth to find out what it is, after all the default state on boot is ok.

From here I pass the ball back. Please, with this knowledge could someone fix up the driver? Most likely it would be better done on the kernel side as the KMS frame buffer is affected too. Of course testing patches should be no problem ;)

Thanks!

[Ilia Mirkin (imirkin)]

(In reply to comment #61)
> At the end I got what I wanted. The winner is:
> nvapoke 00100080 e1000000
>
> This register is e0000000 after suspend or after clean boot. So all this
> trouble only because of a single bit was not set ;(

Fantastic! I was secretly hoping that by ignoring the issue for a short while, one of the hardware owners would step up and work it out :)

Looks like register 100080 isn't documented in rnndb. In the linux source it's referred to as NV04_PFB_DEBUG_0. Unfortunately on a quick grep of the code, nothing ever touches bit 24 of that register.

There are three ways forward:

1. Set it for all nv04:nv50 cards
2. Set it for nv28 cards
3. Reach out to nvidia and see if they'll be kind enough to let us know the meaning of that bit, and when we should be setting it. They've been fielding some questions of late, and this seems likely to be one that they'd answer.

[Nv28m (nv28m)]

For the first two options I think it could be useful to grep through all those dumps collected over the years and check which cards have this set.

Option 3 could definately tell if it's only used for a particular memory configuration of this chip, or it's more general (e.g. first 2 options).

By the way I've checked again my earlier claim about being slower after suspend, and it's definately like that. Scrolling is more or less smooth (considering the age of hardware and the resolution used) after kexec-ing from nvidia to nouveau.

But after a suspend it's really "choppy" (same software still running, nothing was changed). The speed is similarly slow after a clean boot too, so it's not a suspend problem. Somewhere the handbrake needs to be released I guess...

[Ilia Mirkin (imirkin)]

(In reply to comment #63)
> For the first two options I think it could be useful to grep through all
> those dumps collected over the years and check which cards have this set.

Yeah, I'll try to have a look later on.

>
> Option 3 could definately tell if it's only used for a particular memory
> configuration of this chip, or it's more general (e.g. first 2 options).

I've fired off a question to NVIDIA, hopefully they'll respond. Sometimes they respond ~immediately, other times it takes two months, but so far they haven't dropped anything on the floor.

>
> By the way I've checked again my earlier claim about being slower after
> suspend, and it's definately like that. Scrolling is more or less smooth
> (considering the age of hardware and the resolution used) after kexec-ing
> from nvidia to nouveau.
>
> But after a suspend it's really "choppy" (same software still running,
> nothing was changed). The speed is similarly slow after a clean boot too, so
> it's not a suspend problem. Somewhere the handbrake needs to be released I
> guess...

Well, you may have just become the resident expert on NV2x cards. You have all the tools we have, and you also have the hardware, which is very hard to come by (a mobile NV2x). Poke around, let us know :) We hang out on #nouveau on irc.freenode.net if you have any questions.

[Nv28m (nv28m)]

I've wasted a lot of time with the mmio registers to find out why things go slow. But it seems it's something else.

Just loading the nvidia kernel module without starting X is enough to make nouveau go fast after kexec.

I did an mmio trace while loading the module, but it only wrote 140 to 0, and that was all. I've checked the PCI config space, also nothing interesting.

Any tips how to find out what happens?

[Ilia Mirkin (imirkin)]

BTW, interesting. In your VBIOS, it tells us to do

0xcbf2: 7a 80 00 10 00 00 00 00 e0 ZM_REG R[0x100080] = 0xe0000000

Which is why that bit gets lost on resume (but not on kexec, since init scripts don't run, since the adapter is already init'd). Good to know, that means that any fixup would have to be made _after_ the bios gets executed... or more likely, as part of the COMPUTE_MEM thing (meminit in core/subdev/devinit/nv20.c), which gets executed in "init script 5", which happens after that "init script 1" which contains the 0x100080 = 0xe0000000 command. Although then it wouldn't happen on boot, so nevermind. Has to happen after the vbios executes.

[Ilia Mirkin (imirkin)]

Even more interesting, your trace actually has

[0] 1012.956817 MMIO32 R 0x100080 0xe1000000 PFB+0x80 => 0xe1000000
[0] 1012.956820 MMIO32 W 0x100080 0xe1000000 PFB+0x80 <= 0xe1000000

Which means that it _starts out_ at 0xe1000000. Was this trace done on a clean boot, or had the nvidia module already been loaded? The latter makes more sense...

[Nv28m (nv28m)]

Yes, it was taken after several attempts, that's why it was already set. I've made a better dump and sent it in e-mail now. According to this it's set the first time it's written to.

[R-ductor (r-ductor)]

Hi, I do not know if it may be still relevant after nv28m dicoveries but here's some quick info (with a debian testing fully updated a month ago).

Booting with plain nouveau (agp v2 4x): distorted mouse, nothing new here :(

I tried to boot the following kernel command lines:

* nouveau.vram_pushbuf=1 TTY and X screwed up.

* nouveau.agpmode=2 -->distorted mouse

* nouveau.agpmode=1 mouse OK, NO apparent problems. Then I tried then a glxgears that gave a GPU lockup, alas.

* nouveau.agpmode=0 mouse OK, NO apparent problems (yet).

cheers
ric

[Bib (bybeu)]

Guys, if I can help in any maneer I'd be glad. I want you to know my video adapter is flashed with a bios update I found long time ago on dell's site (in my memory, this was a bios update for Windows).

[Nv28m (nv28m)]

nouveau.agpmode=0 seems to work here too, also after comming back from suspend.

Still I think I'm stuck with the modesetting driver with the bit 24 hack in boot/suspend scripts. The scrolling and rxvt performance is just better.

[Bib (bybeu)]

I reached to retreive my video bios version*:
cat /proc/driver/nvidia/cards/0
Model: GeForce4 4200 Go
IRQ: 11
Video BIOS: 04.28.20.31.c1
Card Type: AGP
DMA Size: 32 bits
DMA Mask: 0xffffffff

Maybe you will like to check against your own and tell me you need something else from me.

* not that difficult, but I'm unskilled where/what to dig in.

Bye bye

[Andrew Kurn (kurn)]

(In reply to nv28m from comment #71)
> nouveau.agpmode=0 seems to work here too, also after comming back from
> suspend.
>
> Still I think I'm stuck with the modesetting driver with the bit 24 hack in
> boot/suspend scripts. The scrolling and rxvt performance is just better.

The parameter name seems to be changed. nouveau.modeset=0 is what worked for me.

I add my thanks for the hard work done by Mr. nv28m.

[Andrew Kurn (kurn)]

(In reply to Ilia Mirkin from comment #64)
> (In reply to comment #63)

> >
> > Option 3 could definately tell if it's only used for a particular memory
> > configuration of this chip, or it's more general (e.g. first 2 options).
>
> I've fired off a question to NVIDIA, hopefully they'll respond. Sometimes
> they respond ~immediately, other times it takes two months, but so far they
> haven't dropped anything on the floor.

Well, now that it's more than a year, I think the floor can be considered the likely destination. It would be nice to have an answer, but it's no longer likely.

I think a fall-back to #2 (set the bit for N28 chips) is the most reasonable. If all the other chips needed it, we'd have seen a flood of bug reports by now. It's not as if this bug isn't obvious. X is unusable until it's fixed.

[Ilia Mirkin (imirkin)]

(In reply to AndrewK from comment #73)
> (In reply to nv28m from comment #71)
> > nouveau.agpmode=0 seems to work here too, also after comming back from
> > suspend.
> >
> > Still I think I'm stuck with the modesetting driver with the bit 24 hack in
> > boot/suspend scripts. The scrolling and rxvt performance is just better.
>
> The parameter name seems to be changed. nouveau.modeset=0 is what worked
> for me.
>
> I add my thanks for the hard work done by Mr. nv28m.

nouveau.modeset=0 just disables nouveau entirely.

[Andrew Kurn (kurn)]

(In reply to Ilia Mirkin from comment #75)
> (In reply to AndrewK from comment #73)
> > (In reply to nv28m from comment #71)
> > > nouveau.agpmode=0 seems to work here too, also after comming back from
> > > suspend.
> > >
> > The parameter name seems to be changed. nouveau.modeset=0 is what worked
> > for me.
> >
>
> nouveau.modeset=0 just disables nouveau entirely.

Without modeset=0 the screen gets scrambled. With it, it is correct.
That's at least minimum functionality.

I tried agpmode=0 but it didn't work. Also, modinfo didn't list a
parameter by that name, so I chose the one that looked closest.

I don't really know what happened, but I'm not demanding w.r.t. high-speed
rendering, so I'm content.

As other posters have mentioned, I'll be glad to do any tests you'd like,
since I have the hardware.

[Emil-l-velikov (emil-l-velikov)]

agpmode and modeset are not even remotely related I'm afraid. With 4.3 onward one should be using nouveau.config="NvAGP=0" as documented [1]

[1] http://nouveau.freedesktop.org/wiki/KernelModuleParameters/#config

[Jonas (jothro)]

On Lubuntu 14.04.3 (I think it's Kernel 3.19.x) "nouveau.agpmode=0" also works, although standby still doesn't seem to work.
What I want to note though, is, that activating the Shadow Framebuffer in /etc/X11/xorg.conf.d/20-nouveau.conf results in a substantial performance increase regarding scrolling and so on.
Maybe this should be considered for the nv28m-cards.

[Andrew Kurn (kurn)]

(In reply to Emil Velikov from comment #77)
> agpmode and modeset are not even remotely related I'm afraid. With 4.3
> onward one should be using nouveau.config="NvAGP=0" as documented [1]
>
> [1] http://nouveau.freedesktop.org/wiki/KernelModuleParameters/#config

Yes. The syntax given seems to do the trick. Thanks much.

[Martin-peres-n (martin-peres-n)]

-- 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/29.