|
Description
r.ductor
2012-09-09 18:46:01 UTC
Created attachment 66890 [details]
dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64
Created attachment 66892 [details]
Xorg.0.log
nvdia just released a new driver: see https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/948053 post #119 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. Created attachment 82135 [details]
output of dmesg 2013-07-06
Created attachment 82136 [details]
Xorg.0.log v2013-07-06
Created attachment 82138 [details]
dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64 #2013-07-06
Created attachment 82139 [details]
output of lsmod (2013-07-06)
Created attachment 82140 [details]
output of sysctl --all (2013-07-06)
.... 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) ... 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
$
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 ? 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.
(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 Created attachment 82146 [details]
dmesg with nvidia driver (2013-07-06)
Created attachment 82147 [details]
Xorg.0.log with nvidia driver
... further info ... I've attached dmesg and Xorg.0.log obtained when the nvidia driver 96.43.23 was running (and everything seemed fine) (In reply to comment #12) > Have you tried with a plain (empty) xorg.conf ? # cat /etc/X11/xorg.conf # Done, same misbehavior. (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 (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 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. (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. (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. Created attachment 82378 [details]
Photo of external vga monitor. Distorted iceweasel logo and double coursor.
Created attachment 82379 [details]
xrandr log of test with external VGA monitor
Created attachment 82380 [details]
dmesg when booting with external VGA monitor
Created attachment 82381 [details]
Xorg.log when booting with external VGA monitor
Created attachment 82382 [details]
Photo of external vga monitor. Distorted iceweasel logo and double coursor.
For comparison I add some info when the nvidia legacy driver is used: xrandr output, dmesg, Xorg.0.log Created attachment 82386 [details]
xrandr with nvidia legacy
Created attachment 82387 [details]
xorg.log with nvidia legacy
Created attachment 82388 [details]
dmesg with nvidia legagcy
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) :) 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) :) > > (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 Created attachment 83141 [details]
fractal_97_1862x1048 not rescaled by iceweasel
Created attachment 83142 [details]
fractal_97_1862x1048 not rescaled by iceweasel
Created attachment 83143 [details]
fractal_97_1862x1048 not rescaled by iceweasel
Created attachment 83144 [details]
fractal_97_1862x1048 ***rescaled*** by iceweasel
converted to jpg by gimp to decrease the size
Created attachment 83145 [details]
fractal_97_1862x1048 ***rescaled*** by iceweasel
Created attachment 83146 [details]
fractal2 recaled and not rescaled by iceweasel
Created attachment 83147 [details]
dmesg after nouveau/GPU crash
Created attachment 83148 [details]
links2 -g &> output (graphics in framebuffer)
Created attachment 83149 [details]
links -g rendered graphics in framebuffer
Created attachment 83150 [details]
links2 framebuffer graphics: the same fractal
Created attachment 83151 [details]
just another horrible view of my problem....
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)
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) (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 (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) 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 ? *** Bug 50403 has been marked as a duplicate of this bug. *** 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? 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. 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? 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 (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.) 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). 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. 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 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! (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. 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... (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. 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? 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. 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... 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. 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 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). 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. 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 (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. (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. (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. (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. 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 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. (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. -- 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. |
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.