Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

2021-03-27 Thread Daniel James
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



Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

2019-11-15 Thread Daniel James
On Thu, 31 Oct 2019 15:46:30 + Daniel James 
 wrote:
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 :00:05.0: NVIDIA C51 (04e000a2)
[2.752186] nouveau :00:05.0: bios: version 05.51.22.33.07
[2.753091] nouveau :00:05.0: fb: 128 MiB of unknown memory type
[4.052950] nouveau :00:05.0: DRM: VRAM: 125 MiB
[4.052985] nouveau :00:05.0: DRM: GART: 512 MiB
[4.053022] nouveau :00:05.0: DRM: TMDS table version 1.1
[4.053058] nouveau :00:05.0: DRM: DCB version 3.0
[4.053094] nouveau :00:05.0: DRM: DCB outp 00: 02000300 0023
[4.053131] nouveau :00:05.0: DRM: DCB outp 01: 03011312 
[4.053168] nouveau :00:05.0: DRM: DCB outp 02: 020023f1 0040c080
[4.053205] nouveau :00:05.0: DRM: DCB conn 00: 
[4.053240] nouveau :00:05.0: DRM: DCB conn 01: 0131
[4.053275] nouveau :00:05.0: DRM: DCB conn 02: 0210
[4.053311] nouveau :00:05.0: DRM: DCB conn 03: 0211
[4.053346] nouveau :00:05.0: DRM: DCB conn 04: 0213
[4.054701] nouveau :00:05.0: DRM: MM: using M2MF for buffer copies
[4.055157] nouveau :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 :00:05.0: DRM: Setting dpms mode 3 on TV 
encoder (output 2)
[4.176611] nouveau :00:05.0: DRM: allocated 1920x1200 fb: 
0x9000, bo (ptrval)

[4.218180] fbcon: nouveaudrmfb (fb0) is primary device
[4.329239] nouveau :00:05.0: fb0: nouveaudrmfb frame buffer device
[4.345656] [drm] Initialized nouveau 1.3.1 20120801 for :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.


--



Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

2019-10-31 Thread Daniel James

On Thu, 31 Oct 2019 10:31:48 +0100 Sven Joachim  wrote:


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.


Yes, I assumed vesa.

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.


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

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.


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



> 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 think you are right here.

> [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

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


Without nomodeset I get:

[2.722181] nouveau :00:05.0: NVIDIA C51 (04e000a2)
[2.731283] nouveau :00:05.0: bios: version 05.51.22.33.07
[2.732373] nouveau :00:05.0: fb: 128 MiB of unknown memory type
[4.033290] nouveau :00:05.0: DRM: VRAM: 125 MiB
[4.033325] nouveau :00:05.0: DRM: GART: 512 MiB
[4.033363] nouveau :00:05.0: DRM: TMDS table version 1.1
[4.033399] nouveau :00:05.0: DRM: DCB version 3.0
[4.033435] nouveau :00:05.0: DRM: DCB outp 00: 02000300 0023
[4.036555] nouveau :00:05.0: DRM: DCB outp 01: 03011312 
[4.036592] nouveau :00:05.0: DRM: DCB outp 02: 020023f1 0040c080
[4.036629] nouveau :00:05.0: DRM: DCB conn 00: 
[4.036664] nouveau :00:05.0: DRM: DCB conn 01: 0131
[4.036699] nouveau :00:05.0: DRM: DCB conn 02: 0210
[4.036735] nouveau :00:05.0: DRM: DCB conn 03: 0211
[4.036770] nouveau :00:05.0: DRM: DCB conn 04: 0213
[4.037233] nouveau :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 :00:05.0: DRM: Setting dpms mode 3 on TV 
encoder (output 2)
[4.174450] nouveau :00:05.0: DRM: allocated 1920x1200 fb: 
0x8000, bo (ptrval)

[4.217697] fbcon: nouveaufb (fb0) is primary device
[4.357759] nouveau :00:05.0: fb0: nouveaufb frame buffer device
[4.376957] [drm] Initialized nouveau 1.3.1 20120801 for :00:05.0 
on minor 0


(Sorry, Thunderbird has made some lines wrap)

With nomodeset no lines match.


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.


As I said: Stretch works fine as it is. That is: The Stretch kernel 
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 ...


--
Regards,
  Daniel James



Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

2019-10-31 Thread Sven Joachim
On 2019-10-30 16:58 +, Daniel James wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.16-1
> Severity: important
> File: nouveau
>
> 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).

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.

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

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.

> 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 think you are right here.

> [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

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



Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

2019-10-30 Thread Daniel James

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: important
File: nouveau

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.



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51PV 
[GeForce 6150] [10de:0240] (rev a2)


/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)


Xorg X server log files on system:
--
-rw-r--r-- 1 daniel daniel 33547 Oct 13 15:34 
/home/daniel/.local/share/xorg/Xorg.0.log

-rw-r--r-- 1 root   root   26008 Oct 29 16:57 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[45.542]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[45.542] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[45.542] Current Operating System: Linux welly-buster 4.19.0-6-amd64 
#1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64
[45.542] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64 
root=UUID=4abd25ab-9425-42ee-8612-75c0164d13d5 ro noapic

[45.542] Build Date: 05 March 2019  08:11:12PM
[45.542] xorg-server 2:1.20.4-1 (https://www.debian.org/support)
[45.542] Current version of pixman: 0.36.0
[45.542]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[45.542] Markers: (--) probed, (**) from config file, (==) default 
setting,

(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[45.543] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 29 
16:57:10 2019

[45.543] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[45.543] (==) No Layout section.  Using the first Screen section.
[45.543] (==) No screen section available. Using defaults.
[45.543] (**) |-->Screen "Default Screen Section" (0)
[45.543] (**) |   |-->Monitor ""
[45.544] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[45.544] (==) Automatically adding devices
[45.544] (==) Automatically enabling devices
[45.544] (==) Automatically adding GPU devices
[45.544] (==) Max clients allowed: 256, resource mask: 0x1f
[45.545] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.

[45.545]Entry deleted from font path.
[45.545] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[45.545] (==) ModulePath set to "/usr/lib/xorg/modules"
[45.545] (II) The server relies on udev to provide the list of input 
devices.

If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[45.545] (II) Loader magic: 0x562deaa57e20
[45.545] (II) Module ABI