Bug 54700 - Distorted graphics (double cursor) with GeForce 4200Go (NV28M)
Summary: Distorted graphics (double cursor) with GeForce 4200Go (NV28M)
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 6.7.0
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 50403 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-09-09 18:46 UTC by r.ductor
Modified: 2016-01-27 07:24 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg output (47.38 KB, text/plain)
2012-09-09 18:46 UTC, r.ductor
no flags Details
dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64 (64.00 KB, text/plain)
2012-09-09 18:49 UTC, r.ductor
no flags Details
Xorg.0.log (33.16 KB, text/plain)
2012-09-09 18:50 UTC, r.ductor
no flags Details
output of dmesg 2013-07-06 (44.02 KB, text/plain)
2013-07-07 12:24 UTC, r.ductor
no flags Details
Xorg.0.log v2013-07-06 (31.14 KB, text/plain)
2013-07-07 12:25 UTC, r.ductor
no flags Details
dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64 #2013-07-06 (64.00 KB, text/plain)
2013-07-07 12:26 UTC, r.ductor
no flags Details
output of lsmod (2013-07-06) (3.90 KB, text/plain)
2013-07-07 12:27 UTC, r.ductor
no flags Details
output of sysctl --all (2013-07-06) (23.57 KB, text/plain)
2013-07-07 12:28 UTC, r.ductor
no flags Details
distorted graphics (43.75 KB, image/png)
2013-07-07 15:48 UTC, r.ductor
no flags Details
dmesg with nvidia driver (2013-07-06) (40.66 KB, text/plain)
2013-07-07 16:24 UTC, r.ductor
no flags Details
Xorg.0.log with nvidia driver (21.13 KB, text/plain)
2013-07-07 16:25 UTC, r.ductor
no flags Details
Photo of external vga monitor. Distorted iceweasel logo and double coursor. (2.85 MB, text/plain)
2013-07-13 09:51 UTC, r.ductor
no flags Details
xrandr log of test with external VGA monitor (4.56 KB, text/plain)
2013-07-13 09:52 UTC, r.ductor
no flags Details
dmesg when booting with external VGA monitor (44.15 KB, text/plain)
2013-07-13 09:52 UTC, r.ductor
no flags Details
Xorg.log when booting with external VGA monitor (52.82 KB, text/plain)
2013-07-13 09:53 UTC, r.ductor
no flags Details
Photo of external vga monitor. Distorted iceweasel logo and double coursor. (2.86 MB, image/jpeg)
2013-07-13 10:00 UTC, r.ductor
no flags Details
xrandr with nvidia legacy (6.06 KB, text/plain)
2013-07-13 11:56 UTC, r.ductor
no flags Details
xorg.log with nvidia legacy (21.13 KB, text/plain)
2013-07-13 11:56 UTC, r.ductor
no flags Details
dmesg with nvidia legagcy (40.70 KB, text/plain)
2013-07-13 11:57 UTC, r.ductor
no flags Details
fractal_97_1862x1048 not rescaled by iceweasel (2.52 MB, text/plain)
2013-07-28 18:18 UTC, r.ductor
no flags Details
fractal_97_1862x1048 not rescaled by iceweasel (2.52 MB, image/jpeg)
2013-07-28 18:19 UTC, r.ductor
no flags Details
fractal_97_1862x1048 not rescaled by iceweasel (2.52 MB, image/png)
2013-07-28 18:20 UTC, r.ductor
no flags Details
fractal_97_1862x1048 ***rescaled*** by iceweasel (1.38 MB, text/plain)
2013-07-28 18:24 UTC, r.ductor
no flags Details
fractal_97_1862x1048 ***rescaled*** by iceweasel (1.38 MB, image/jpeg)
2013-07-28 18:25 UTC, r.ductor
no flags Details
fractal2 recaled and not rescaled by iceweasel (1.54 MB, image/png)
2013-07-28 18:27 UTC, r.ductor
no flags Details
dmesg after nouveau/GPU crash (45.76 KB, text/plain)
2013-07-28 18:28 UTC, r.ductor
no flags Details
links2 -g &> output (graphics in framebuffer) (2.49 KB, text/plain)
2013-07-28 18:29 UTC, r.ductor
no flags Details
links -g rendered graphics in framebuffer (2.75 MB, image/jpeg)
2013-07-28 18:34 UTC, r.ductor
no flags Details
links2 framebuffer graphics: the same fractal (1.56 MB, image/jpeg)
2013-07-28 18:37 UTC, r.ductor
no flags Details
just another horrible view of my problem.... (1.38 MB, image/png)
2013-07-28 18:49 UTC, r.ductor
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description r.ductor 2012-09-09 18:46:01 UTC
Created attachment 66889 [details]
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) (debian-kernel@lists.debian.org) (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 <debian-x@lists.debian.org>
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/
Comment 1 r.ductor 2012-09-09 18:49:06 UTC
Created attachment 66890 [details]
dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64
Comment 2 r.ductor 2012-09-09 18:50:12 UTC
Created attachment 66892 [details]
Xorg.0.log
Comment 3 VF 2012-09-09 19:15:44 UTC
nvdia just released a new driver: see https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/948053 post #119
Comment 4 r.ductor 2013-07-07 12:16:54 UTC
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 <debian-x@lists.debian.org>
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.
Comment 5 r.ductor 2013-07-07 12:24:21 UTC
Created attachment 82135 [details]
output of dmesg 2013-07-06
Comment 6 r.ductor 2013-07-07 12:25:04 UTC
Created attachment 82136 [details]
Xorg.0.log v2013-07-06
Comment 7 r.ductor 2013-07-07 12:26:26 UTC
Created attachment 82138 [details]
dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64 #2013-07-06
Comment 8 r.ductor 2013-07-07 12:27:39 UTC
Created attachment 82139 [details]
output of lsmod (2013-07-06)
Comment 9 r.ductor 2013-07-07 12:28:43 UTC
Created attachment 82140 [details]
output of sysctl --all (2013-07-06)
Comment 10 r.ductor 2013-07-07 12:34:54 UTC
.... 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)
Comment 11 r.ductor 2013-07-07 14:00:30 UTC
... 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          PAL-M        PAL-N        PAL-Nc                                                   
                           PAL-60       NTSC-M       NTSC-J                                                                
        bottom margin: 50 (0x00000032)  range:  (0,100)                                                                    
        left margin: 50 (0x00000032)    range:  (0,100)                                                                    
        subconnector:   Unknown                                                                                            
                supported: Unknown      Composite    SVIDEO       Component                                                
                           SCART                                                                                           
        select subconnector:    Automatic                                                                                  
                supported: Automatic    Composite    SVIDEO       Component                                                
                           SCART                                                                                           
        dithering mode: auto                                                                                               
                supported: auto         off          on                                                                    
        scaling mode:   Full                                                                                               
                supported: None         Full         Center       Full aspect                                              
  1920x1200 (0x54)  161.8MHz -HSync -VSync *current +preferred                                                             
        h: width  1920 start 2020 end 2052 total 2184 skew    0 clock   74.1KHz                                            
        v: height 1200 start 1202 end 1208 total 1235           clock   60.0Hz                                             
  1920x1200 (0x55)  193.2MHz -HSync +VSync                                                                                 
        h: width  1920 start 2056 end 2256 total 2592 skew    0 clock   74.6KHz
        v: height 1200 start 1203 end 1209 total 1245           clock   59.9Hz
  1920x1080 (0x56)  173.0MHz -HSync +VSync
        h: width  1920 start 2048 end 2248 total 2576 skew    0 clock   67.2KHz
        v: height 1080 start 1083 end 1088 total 1120           clock   60.0Hz
  1600x1200 (0x57)  161.0MHz -HSync +VSync
        h: width  1600 start 1712 end 1880 total 2160 skew    0 clock   74.5KHz
        v: height 1200 start 1203 end 1207 total 1245           clock   59.9Hz
  1680x1050 (0x58)  146.2MHz -HSync +VSync
        h: width  1680 start 1784 end 1960 total 2240 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1059 total 1089           clock   60.0Hz
  1400x1050 (0x59)  121.8MHz -HSync +VSync
        h: width  1400 start 1488 end 1632 total 1864 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1057 total 1089           clock   60.0Hz
  1280x1024 (0x5a)  109.0MHz -HSync +VSync
        h: width  1280 start 1368 end 1496 total 1712 skew    0 clock   63.7KHz
        v: height 1024 start 1027 end 1034 total 1063           clock   59.9Hz
  1280x960 (0x5b)  101.2MHz -HSync +VSync
        h: width  1280 start 1360 end 1488 total 1696 skew    0 clock   59.7KHz
        v: height  960 start  963 end  967 total  996           clock   59.9Hz
  1152x864 (0x5c)   81.8MHz -HSync +VSync
        h: width  1152 start 1216 end 1336 total 1520 skew    0 clock   53.8KHz
        v: height  864 start  867 end  871 total  897           clock   60.0Hz
  1024x768 (0x5d)   63.5MHz -HSync +VSync
        h: width  1024 start 1072 end 1176 total 1328 skew    0 clock   47.8KHz
        v: height  768 start  771 end  775 total  798           clock   59.9Hz
  800x600 (0x5e)   38.2MHz -HSync +VSync
        h: width   800 start  832 end  912 total 1024 skew    0 clock   37.4KHz
        v: height  600 start  603 end  607 total  624           clock   59.9Hz
  640x480 (0x5f)   23.8MHz -HSync +VSync
        h: width   640 start  664 end  720 total  800 skew    0 clock   29.7KHz
        v: height  480 start  483 end  487 total  500           clock   59.4Hz
  720x400 (0x60)   22.2MHz -HSync +VSync
        h: width   720 start  744 end  808 total  896 skew    0 clock   24.8KHz
        v: height  400 start  403 end  413 total  417           clock   59.6Hz
  640x400 (0x61)   20.0MHz -HSync +VSync
        h: width   640 start  664 end  720 total  800 skew    0 clock   25.0KHz
        v: height  400 start  403 end  409 total  417           clock   60.0Hz
  640x350 (0x62)   17.5MHz -HSync +VSync
        h: width   640 start  664 end  720 total  800 skew    0 clock   21.9KHz
        v: height  350 start  353 end  363 total  366           clock   59.8Hz
DVI-D-1 disconnected (normal left inverted right x axis y axis)
        Identifier: 0x53
        Timestamp:  24877
        Subpixel:   unknown
        Clones:    
        CRTCs:      0 1
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
        dithering mode: auto
                supported: auto         off          on          
        scaling mode:   Full
                supported: None         Full         Center       Full aspect 
$
Comment 12 Emil Velikov 2013-07-07 14:12:13 UTC
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 ?
Comment 13 r.ductor 2013-07-07 15:48:15 UTC
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.
Comment 14 r.ductor 2013-07-07 16:20:49 UTC
(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
Comment 15 r.ductor 2013-07-07 16:24:30 UTC
Created attachment 82146 [details]
dmesg with nvidia driver (2013-07-06)
Comment 16 r.ductor 2013-07-07 16:25:05 UTC
Created attachment 82147 [details]
Xorg.0.log with nvidia driver
Comment 17 r.ductor 2013-07-07 16:27:45 UTC
... further info ...

I've attached dmesg and Xorg.0.log obtained when the nvidia driver 96.43.23 was running (and everything seemed fine)
Comment 18 r.ductor 2013-07-07 16:34:17 UTC
(In reply to comment #12)
>  Have you tried with a plain (empty) xorg.conf ?

# cat /etc/X11/xorg.conf
#

Done, same misbehavior.
Comment 19 Emil Velikov 2013-07-07 17:38:48 UTC
(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
Comment 20 Emil Velikov 2013-07-07 17:47:45 UTC
(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
Comment 21 Ilia Mirkin 2013-07-07 17:51:59 UTC
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.
Comment 22 r.ductor 2013-07-08 09:14:50 UTC
(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.
Comment 23 r.ductor 2013-07-13 09:48:26 UTC
(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.
Comment 24 r.ductor 2013-07-13 09:51:16 UTC
Created attachment 82378 [details]
Photo of external vga monitor. Distorted iceweasel logo and double coursor.
Comment 25 r.ductor 2013-07-13 09:52:08 UTC
Created attachment 82379 [details]
xrandr log of test with external VGA monitor
Comment 26 r.ductor 2013-07-13 09:52:56 UTC
Created attachment 82380 [details]
dmesg when booting with external VGA monitor
Comment 27 r.ductor 2013-07-13 09:53:37 UTC
Created attachment 82381 [details]
Xorg.log when booting with external VGA monitor
Comment 28 r.ductor 2013-07-13 10:00:00 UTC
Created attachment 82382 [details]
Photo of external vga monitor. Distorted iceweasel logo and double coursor.
Comment 29 r.ductor 2013-07-13 11:55:05 UTC
For comparison I add some info when the nvidia legacy driver is used: xrandr output, dmesg, Xorg.0.log
Comment 30 r.ductor 2013-07-13 11:56:08 UTC
Created attachment 82386 [details]
xrandr with nvidia legacy
Comment 31 r.ductor 2013-07-13 11:56:47 UTC
Created attachment 82387 [details]
xorg.log with nvidia legacy
Comment 32 r.ductor 2013-07-13 11:57:56 UTC
Created attachment 82388 [details]
dmesg with nvidia legagcy
Comment 33 Emil Velikov 2013-07-24 00:55:04 UTC
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) :)
Comment 34 r.ductor 2013-07-24 09:02:05 UTC
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 bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=54700
> 
> --- Comment #33 from Emil Velikov <emil.l.velikov@gmail.com> ---
> 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) :)
> 
>
Comment 35 Emil Velikov 2013-07-24 11:33:58 UTC
(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
Comment 36 r.ductor 2013-07-28 18:18:03 UTC
Created attachment 83141 [details]
fractal_97_1862x1048 not rescaled by iceweasel
Comment 37 r.ductor 2013-07-28 18:19:25 UTC
Created attachment 83142 [details]
fractal_97_1862x1048 not rescaled by iceweasel
Comment 38 r.ductor 2013-07-28 18:20:46 UTC
Created attachment 83143 [details]
fractal_97_1862x1048 not rescaled by iceweasel
Comment 39 r.ductor 2013-07-28 18:24:28 UTC
Created attachment 83144 [details]
fractal_97_1862x1048 ***rescaled*** by iceweasel

converted to jpg by gimp to decrease the size
Comment 40 r.ductor 2013-07-28 18:25:32 UTC
Created attachment 83145 [details]
fractal_97_1862x1048 ***rescaled*** by iceweasel
Comment 41 r.ductor 2013-07-28 18:27:29 UTC
Created attachment 83146 [details]
fractal2 recaled and not rescaled by iceweasel
Comment 42 r.ductor 2013-07-28 18:28:15 UTC
Created attachment 83147 [details]
dmesg after nouveau/GPU crash
Comment 43 r.ductor 2013-07-28 18:29:18 UTC
Created attachment 83148 [details]
links2 -g &> output (graphics in framebuffer)
Comment 44 r.ductor 2013-07-28 18:34:06 UTC
Created attachment 83149 [details]
links -g  rendered graphics in framebuffer
Comment 45 r.ductor 2013-07-28 18:37:36 UTC
Created attachment 83150 [details]
links2 framebuffer graphics: the same fractal
Comment 46 r.ductor 2013-07-28 18:49:56 UTC
Created attachment 83151 [details]
just another horrible view of my problem....
Comment 47 r.ductor 2013-07-28 19:00:08 UTC
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 asked, i.e. a transition point in sizes from which distortion starts, seems more an iceweasel bug. See also attachment "looking for iceweasel logo". 

3) the problem of corruption from rescaling to built-in viewers seems not there with the built in konqueror viewer and gwenviewer....

4) running the various tests I got 2 crashes (black screen) :(((( see dmesg in attachment

5 [review]) to test the graphics in framebuffer, I've installed links2 ( http://links.twibright.com/ ) which is a web browser with graphic capabilities working also in framebuffer. Output is 100% corrupted, see photos attachments. (Of course I do not know if this is a link2 problem. I attached the console error output of links2.

Regards
ric
(I'll disappear for 3 weeks sorry)
Comment 48 Emil Velikov 2013-07-29 00:43:24 UTC
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)
Comment 49 r.ductor 2013-07-31 07:29:33 UTC
(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:                                                                                                                          
[  532.112101] nouveau  [     DRM] 0xDFB9: Parsing digital output script table                                                                                                     
[  532.698125] nouveau  [     DRM] Calling LVDS script 2:                                                                                                                          
[  532.698131] nouveau  [     DRM] 0xDFE7: Parsing digital output script table                                                                                                     
[  532.714020] nouveau  [     DRM] Calling LVDS script 5:                                                                                                                          
[  532.714026] nouveau  [     DRM] 0xDF32: Parsing digital output script table                                                                                                     
[  533.015868] nouveau E[     DRM] GPU lockup - switching to software fbcon                                                                                                        
[  539.148515] nouveau  [     DRM] Calling LVDS script 6:                                                                                                                          
[  539.148531] nouveau  [     DRM] 0xDFB9: Parsing digital output script table
[  539.734534] nouveau  [     DRM] Calling LVDS script 2:
[  539.734545] nouveau  [     DRM] 0xDFE7: Parsing digital output script table
[  539.750439] nouveau  [     DRM] Calling LVDS script 5:
[  539.750449] nouveau  [     DRM] 0xDF32: Parsing digital output script table
[  542.968042] nouveau E[Xorg[2328]] failed to idle channel 0xcccc0000 [Xorg[2328]]
[  545.992030] nouveau E[Xorg[2328]] failed to idle channel 0xcccc0000 [Xorg[2328]]
[  546.009560] nouveau  [     DRM] Calling LVDS script 6:
[  546.009569] nouveau  [     DRM] 0xDFB9: Parsing digital output script table
[  549.752032] nouveau E[glxgears[3681]] failed to idle channel 0xcccc0000 [glxgears[3681]]
[  552.772032] nouveau E[glxgears[3681]] failed to idle channel 0xcccc0000 [glxgears[3681]]
[  553.528020] nouveau E[  PGRAPH][0000:01:00.0] idle timed out with status 0x10000501
[  553.850753] nouveau E[  PGRAPH][0000:01:00.0] idle timed out with status 0x10000501
[  554.170128] nouveau E[  PGRAPH][0000:01:00.0] idle timed out with status 0x10000501
[  554.500032] nouveau E[  PGRAPH][0000:01:00.0] idle timed out with status 0x10000501
[  554.878554] nouveau  [     DRM] Calling LVDS script 2:
[  554.878563] nouveau  [     DRM] 0xDFE7: Parsing digital output script table
[  554.894451] nouveau  [     DRM] Calling LVDS script 5:
[  554.894457] nouveau  [     DRM] 0xDF32: Parsing digital output script table
[  558.247972] nouveau  [     DRM] Calling LVDS script 6:
[  558.247980] nouveau  [     DRM] 0xDFB9: Parsing digital output script table
[  558.833993] nouveau  [     DRM] Calling LVDS script 2:
[  558.833998] nouveau  [     DRM] 0xDFE7: Parsing digital output script table
[  558.849888] nouveau  [     DRM] Calling LVDS script 5:
[  558.849894] nouveau  [     DRM] 0xDF32: Parsing digital output script table
Comment 50 Emil Velikov 2013-07-31 14:34:42 UTC
(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)
Comment 51 Emil Velikov 2013-07-31 14:58:21 UTC
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 ?
Comment 52 Ilia Mirkin 2013-08-26 04:24:42 UTC
*** Bug 50403 has been marked as a duplicate of this bug. ***
Comment 53 Emgaron 2013-12-11 15:02:02 UTC
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?
Comment 54 VF 2013-12-11 17:24:42 UTC
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.
Comment 55 nv28m 2014-04-27 07:34:36 UTC
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?
Comment 56 nv28m 2014-04-27 08:48:57 UTC
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
Comment 57 Ilia Mirkin 2014-04-27 17:12:50 UTC
(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 mmio.dumps@gmail.com. (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.)
Comment 58 nv28m 2014-04-27 21:46:35 UTC
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).
Comment 59 nv28m 2014-04-28 18:55:55 UTC
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.
Comment 60 VF 2014-04-30 08:24:52 UTC
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
Comment 61 nv28m 2014-05-01 18:53:48 UTC
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!
Comment 62 Ilia Mirkin 2014-05-01 21:12:26 UTC
(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.
Comment 63 nv28m 2014-05-02 17:17:21 UTC
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...
Comment 64 Ilia Mirkin 2014-05-02 17:28:32 UTC
(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.
Comment 65 nv28m 2014-05-02 21:19:07 UTC
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?
Comment 66 Ilia Mirkin 2014-05-02 23:44:17 UTC
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.
Comment 67 Ilia Mirkin 2014-05-02 23:48:11 UTC
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...
Comment 68 nv28m 2014-05-03 05:45:54 UTC
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.
Comment 69 r.ductor 2014-11-11 18:27:36 UTC
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
Comment 70 VF 2014-11-17 18:40:49 UTC
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).
Comment 71 nv28m 2015-01-02 20:01:08 UTC
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.
Comment 72 VF 2015-02-17 09:09:50 UTC
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
Comment 73 AndrewK 2016-01-21 12:20:07 UTC
(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.
Comment 74 AndrewK 2016-01-21 12:29:48 UTC
(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.
Comment 75 Ilia Mirkin 2016-01-21 19:38:11 UTC
(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.
Comment 76 AndrewK 2016-01-22 01:47:07 UTC
(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.
Comment 77 Emil Velikov 2016-01-22 09:55:34 UTC
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
Comment 78 jjoonnaass2 2016-01-23 20:37:29 UTC
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.
Comment 79 AndrewK 2016-01-27 07:24:46 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.