Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150
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
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
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
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 vers
Bug#780656: xserver-xorg-input-evdev: Logitech wireless keyboard ignores locale in X.org, defaults to en-us
Package: xserver-xorg-input-evdev Version: 1:2.9.0-2 Severity: normal After upgrading a machine from squeeze to wheezy to jessie, my Logitech K400 wireless keyboard no longer functioned correctly. My locale is en-gb but key presses resulted in en-us characters appearing in applications running under X.org, for example the pipe symbol on the keyboard became a chevron on the screen. It appears to be an old bug filed (twice) in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/993827 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/995715 There is a detailed explanation of the issue here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/995715/comments/19 Linux kernel 3.2 introduced the logitech_dj HID driver to explicitly support the Logitech Unifying Receiver. This wireless USB hardware is designed for compatible mice and keyboards so that you only need one dongle for multiple devices. It worked fine for both mice and keyboards under squeeze, using a generic USB driver. However the xserver-xorg-input-evdev package does not seem to support this change of drivers, as far as keyboards are concerned. The workaround is for the display manager startup script to force the locale. In my case, I did this in ~/.fluxbox/startup with the line: setxkbmap gb Thanks! Daniel -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55082579.3040...@64studio.com
Bug#374026: Try deleting dotfiles...
I also experienced keyboard failure after upgrading to Lenny and running Thunderbird. I was replying to a mail and hit ctrl-shift-r, then couldn't type anything else. Logging out with the mouse, the keyboard still worked in gdm and on a virtual console. I noticed that I was the only user on the system with the problem, so I deleted all the .dotfiles in my home directory, and the problem went away. Cheers! Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]