Dear Maintainer,

[Message prepared by reportbug 7.5.3-de10u1 but mailed from Thunderbird
on a different system]

In Debian 10 "Buster" the Nouveau driver does not start correctly unless
the "nomodeset" kernel parameter is supplied.

Without "nomodeset" the system boots to a full-screen graphical login
screen. Login credentials can be entered, but the screen then flashes
off (black) for a fraction of a second and returns to the login dialog.

With "nomodeset" Debian starts but the screen resolution is not optimal,
and cannot be changed. The system boots to a graphical login screen with
the edges black -- apparently a 1280x1024 displayed full-height but
narrower than the screen. When login credentials are entered the system
boots but still only shows a 1280x1024 desktop. Attempts to change the
resolution (e.g. using xrandr to add a new mode and switch to it fail).

The system uses an Asus M2NPV-VM motherboard with NForce 430 chipset and
GeForce 61500 onboard graphics. The monitor is a Dell U2410 which has a
native resolution of 1920x1200 pixels.

On Debian 9 "Stretch" it was not necessary to specify "nomodeset", and
the full screen resolution was used.

This bug report is being prepared from a text console after booting
WITHOUT "nomodeset". The errors ("EE") at 45.875 seem to be crucial. I
have compared /var/log/Xorg.0.log files from this system when booting
Buster and when booting Stretch, and (apart from minor details like
module version numbers and the time field) the logs are identical up to
this point.

With nomodeset X will fallback to the fbev or vesa drivers.  The latter
has very limited support for modern wide screens, the former does not
let you change the resolution at all.

There have been many problems with these onboard graphics, quite a large
fraction of the nouveau bug reports in Debian are from system with it.

I think you are right here.

That's not good.  Can you please send some kernel logs?  Run
"sudo dmesg| grep -E '(drm|nouveau)" to retrieve them.

You may want to try different kernels (4.9 from stretch, 5.2 from
testing and/or 5.3 from unstable) and see if they give better results.

Good luck,
Sven

inxi -G says:

Graphics:
   Device-1: NVIDIA C51PV [GeForce 6150] driver: N/A
   Display: x11 server: X.Org 1.20.4 driver: nouveau,vesa
   unloaded: fbdev,modesetting resolution: 1280x1024~N/A
   OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6

I can change to lower resolutions, and back, just not to higher ones.

Agreed ... but note that this hardware had no difficulties with graphics
in Debian Stretch or Jessie. The failure is new with Buster.

Without nomodeset I get:

[    2.722181] nouveau 0000:00:05.0: NVIDIA C51 (04e000a2)
[    2.731283] nouveau 0000:00:05.0: bios: version 05.51.22.33.07
[    2.732373] nouveau 0000:00:05.0: fb: 128 MiB of unknown memory type
[    4.033290] nouveau 0000:00:05.0: DRM: VRAM: 125 MiB
[    4.033325] nouveau 0000:00:05.0: DRM: GART: 512 MiB
[    4.033363] nouveau 0000:00:05.0: DRM: TMDS table version 1.1
[    4.033399] nouveau 0000:00:05.0: DRM: DCB version 3.0
[    4.033435] nouveau 0000:00:05.0: DRM: DCB outp 00: 02000300 00000023
[    4.036555] nouveau 0000:00:05.0: DRM: DCB outp 01: 03011312 00000000
[    4.036592] nouveau 0000:00:05.0: DRM: DCB outp 02: 020023f1 0040c080
[    4.036629] nouveau 0000:00:05.0: DRM: DCB conn 00: 0000
[    4.036664] nouveau 0000:00:05.0: DRM: DCB conn 01: 0131
[    4.036699] nouveau 0000:00:05.0: DRM: DCB conn 02: 0210
[    4.036735] nouveau 0000:00:05.0: DRM: DCB conn 03: 0211
[    4.036770] nouveau 0000:00:05.0: DRM: DCB conn 04: 0213
[    4.037233] nouveau 0000:00:05.0: DRM: Saving VGA fonts
[    4.075567] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    4.075607] [drm] Driver supports precise vblank timestamp query.
[    4.076570] nouveau 0000:00:05.0: DRM: Setting dpms mode 3 on TV
encoder (output 2)
[    4.174450] nouveau 0000:00:05.0: DRM: allocated 1920x1200 fb:
0x8000, bo (____ptrval____)
[    4.217697] fbcon: nouveaufb (fb0) is primary device
[    4.357759] nouveau 0000:00:05.0: fb0: nouveaufb frame buffer device
[    4.376957] [drm] Initialized nouveau 1.3.1 20120801 for 0000:00:05.0
on minor 0

(Sorry, Thunderbird has made some lines wrap)

With nomodeset no lines match.
works in Stretch using nouveau 1.0.13 with a 4.9 kernel. I haven't tried
the Stretch kernel in Buster ...

(Snippet from /var/log/Xorg.0.log under Stretch)
[    16.673] (II) Module nouveau: vendor="X.Org Foundation"
[    16.673] 	compiled for 1.19.3, module version = 1.0.13
[    16.673] 	Module class: X.Org Video Driver
[    16.673] 	ABI class: X.Org Video Driver, version 23.0

(Snippet from /var/log/Xorg.0.log under Buster)
[    39.974] (II) Module nouveau: vendor="X.Org Foundation"
[    39.974] 	compiled for 1.20.3, module version = 1.0.16
[    39.974] 	Module class: X.Org Video Driver
[    39.974] 	ABI class: X.Org Video Driver, version 24.0

Looks like the video driver ABI version has changed as well as the
version of nouveau ... I guess it wouldn't be simple to mix and match.

I normally try to stay clear of testing and unstable, but I'll try those
when I get a chance ...

Sorry it's taken a while.

With Testing (Kernel 5.2.0, Nouveau 1.0.16) the system boots to a
full-screen graphical login. I can enter my username and password, and
the screen then switches to a garbled version of the desktop (a bit like
an old CRT television whose horizontal hold is incorrectly set, but
static not moving).

On this system, "dmesg | grep -E '(drm|nouveau)'" (as root) gives:

[    2.743125] nouveau 0000:00:05.0: NVIDIA C51 (04e000a2)
[    2.752186] nouveau 0000:00:05.0: bios: version 05.51.22.33.07
[    2.753091] nouveau 0000:00:05.0: fb: 128 MiB of unknown memory type
[    4.052950] nouveau 0000:00:05.0: DRM: VRAM: 125 MiB
[    4.052985] nouveau 0000:00:05.0: DRM: GART: 512 MiB
[    4.053022] nouveau 0000:00:05.0: DRM: TMDS table version 1.1
[    4.053058] nouveau 0000:00:05.0: DRM: DCB version 3.0
[    4.053094] nouveau 0000:00:05.0: DRM: DCB outp 00: 02000300 00000023
[    4.053131] nouveau 0000:00:05.0: DRM: DCB outp 01: 03011312 00000000
[    4.053168] nouveau 0000:00:05.0: DRM: DCB outp 02: 020023f1 0040c080
[    4.053205] nouveau 0000:00:05.0: DRM: DCB conn 00: 0000
[    4.053240] nouveau 0000:00:05.0: DRM: DCB conn 01: 0131
[    4.053275] nouveau 0000:00:05.0: DRM: DCB conn 02: 0210
[    4.053311] nouveau 0000:00:05.0: DRM: DCB conn 03: 0211
[    4.053346] nouveau 0000:00:05.0: DRM: DCB conn 04: 0213
[    4.054701] nouveau 0000:00:05.0: DRM: MM: using M2MF for buffer copies
[    4.055157] nouveau 0000:00:05.0: DRM: Saving VGA fonts
[    4.093998] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    4.094037] [drm] Driver supports precise vblank timestamp query.
[    4.095028] nouveau 0000:00:05.0: DRM: Setting dpms mode 3 on TV
encoder (output 2)
[    4.176611] nouveau 0000:00:05.0: DRM: allocated 1920x1200 fb:
0x9000, bo (____ptrval____)
[    4.218180] fbcon: nouveaudrmfb (fb0) is primary device
[    4.329239] nouveau 0000:00:05.0: fb0: nouveaudrmfb frame buffer device
[    4.345656] [drm] Initialized nouveau 1.3.1 20120801 for 0000:00:05.0
on minor 0

Interestingly, when I switch between "terminals" (is that the right
word?) with Ctrl+Alt+F1 and back with Ctrl+Alt+F7 I see a perfect
desktop display briefly before changing away to the text terminial, and
again when I switch back but this then changes to the garbled display
again. Every time I switch away from the graphics terminal to a text one
and back this happens, for slightly varying time periods but never more
than about half a second.

There are no obvious relevant errors in /var/log/Xorg.0.log (and it's
quite long) -- should I post it here?

I've yet to try unstable ... I haven't any more spare hard drives so I'd
have to overwrite the testing system and I don't want to do that if
there's a chance that it may tell us something.

I reported this bug a long time ago. I had been hoping that by now some
update to Debian would contain a fixed Nouveau that would work as
expected with this old hardware. I'm still hoping ...

I have also been playing around with this myself -- I don't know enough
about video hardware (or anything about the Nouveau driver) to try to
meddle with the source, but I've changed configuration options in a
number of ways to see what would happen.

The first thing I should say is that I think the error lines in
Xorg.0.log are misleading. I had tried to disable acceleration in
Nouveau because it had caused problems in Stretch and earlier. The error
message lines:

[    45.875] (EE) NOUVEAU(0): Error creating GPU channel: -19
[    45.875] (EE) NOUVEAU(0): Error initialising acceleration.  Falling
back to NoAccel
[    45.875] (**) NOUVEAU(0): [COPY] acceleration disabled

seemed to me to be showing that the system was trying to use
acceleration. I have tried disabling acceleration by providing a kernel
parameter (either "noaccel" or "nouveau-noaccel=1") which I think worked
in Stretch, but this does NOT seem to disable acceleration in Buster,
which why I was getting the errors above. Those errors appear to have
masked the actual error, making it harder to diagnose the problem.

If I create a fairly minimal xorg.cong file containing just:

Section "Device"
	Identifier "GeForce_6150"
	Driver "nouveau"
	VendorName "NVIDIA Corporation"
	Option	"NoAccel"
	Option	"AccelMethod" "None"
EndSection

Section "Monitor"
	Identifier "Default monitor"
	VendorName "DELL"
	ModelName "U2410"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device "GeForce_6150"
	Monitor "Default monitor"
EndSection

then acceleration DOES seem to be disabled and I no longer get the
errors in Xorg.0.log.

In this state Buster boots to the login/greeting screen in the monitor's
default resolution of 1920x1200 and I can enter a username and password.
These are validated correctly and the screen blanks for a few moments
and returns to the login/greeter.

If I open a commandline console with ALT+F1 I can log in. If I then try
to start an X session with startx I get the following.

(Sorry, this is retyped by hand on another machine and may not be 100%
correct (and lines may have wrapped). Many of the original lines were
terminated with LF but not CR at the end and so the following lines
appeared indented.


X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.19.0-12-amd64 x86_64 Debian
Current Operating System: Linux welly-buster 4.19.0-16-amd64 #1 SMP
Debian 4.19.191-1 (2021-03-19) x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-16-amd64
root=UUID=4abd25ab-9425-42ee-8612-75c0164d13d5 ro noapic
Build Date: 01 December 2020  05:59:57PM
xorg-server 2:1.20.4-1+deb10u2 (https://www.debian.org/support)
Current version of pixman: 0.36.0
         Before reporting problems, check http://wiki.x.org
         to make sure you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
         (++) from command line, (!!) notice, (II) informational,
         (WW) warnoing, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/daniel/.local/share/xorg/Xorg.1.log", Time: Sat
Mar 27 23:32:08 2021
(==) Using config file: "/etc/X11/xorg.conf"
(==) Uing system config directory "/usr/share/X11/xorg.conf.d"
resize called 1920 1200
usr/lib/xorg/Xorg: symbol lookup error:
/usr/lib/xorg/modules/drivers/nouveau_drv.so: undefined symbol:
exaGetPixmapDriverPrivate
xinit: connection to X server lost

It now seems to me that the main problem is this undefined symbol error,
which is causing the xorg to fail to load.

I hope this is useful. Is there any more information I can provide to
help get this matter resolved?