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?

--
Regards,
  Daniel James

Reply via email to