NVIDIA 520M + nouveau compatibility issue

canolucas · 2024-01-27 17:31:27

Do you know if its possible for the nouveau driver to recognize an NVIDIA 520M GPU ?
I'm currently using propietaly drivers from the AUR (packages: nvidia-390xx-dkms nvidia-390xx-settings nvidia-390xx-utils lib32-nvidia-390xx-utils) however these need to be patched on almost every new version of the kernel, as official support for nvidia 390xx reached EOL, no new version is getting released officially from NVIDIA.

Some time ago I started an attempt to switch to nouveau in case the 390xx drivers will fail on any new version of the kernel, however these attempt was not successfull so far. I followed the official guides on the wiki when attempting to transition to nouveau:

Added nouveau to the MODULES array in /etc/mkinitcpio.conf
Removed every package related to the legacy 390xx drivers: yay -R nvidia-390xx-dkms nvidia-390xx-settings nvidia-390xx-utils lib32-nvidia-390xx-utils
Tried changing the driver in /etc/X11/xorg.conf
In /etc/gdm/custom.conf I tried booting with both WaylandEnable=false and WaylandEnable=true
I tried booting with xf86-video-nouveau installed
Also tried booting with xf86-video-nouveau uninstalled, to allow falling back on the modesetting driver (as suggested in the wiki)
Made sure the nouveau driver is not blacklisted within /etc/modprobe.d/

But all I get is the kernel to boot into the console and then the screen starts to flicker forever. Is there anything I may be missing ?
I think the 520M should be old and simple enough for the nouveau driver to support it, compared to the newer and powerfull new models. Thank you very much in advance, and I'm looking forward to be able to move to the open source driver to avoid this inminent compatibility breakage that will certainly happen in the near future.

Scimmia · 2024-01-27 17:35:34

If you're using the kms hook in mkinitcpio, you'll need to remove it, at least temporarily, and rebuild the initramfs.

canolucas · 2024-01-27 17:39:32

Here is a copy-paste of the HOOKS array:

HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)

FYI when I try to run eglinfo -B it hangs with the following error: eglinfo: eglInitialize failed
Also, the laptop will hang sometimes on reboot (with nvidia propietary packages installed everything goes fine instead).

Here is my jounalctl output:
https://0x0.st/HGh_.txt

It looks like the nouveau driver may be broken for my 520M gpu after all, as it fails so badly...

What do you think ? Is the driver really broken for my old gpu ? It there anything else I can try on my side to boot the thing up ?

Please let me know if any other data/logs may be usefull and i'll attach them to the thread.
Thank you very much, any info regarding this issue will be greatly appreciated.

Last edited by canolucas (2024-01-27 21:45:24)

seth · 2024-01-27 20:57:15

There's https://bbs.archlinux.org/viewtopic.php?id=292066
This journal:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

The MEGA.nz stuff is 16MB covering the last week…

canolucas · 2024-01-27 21:44:43

First of all, thanks for the reply.

Sadly, my issue doesn't seem related to the aforementioned post, because that issue was solved in the latest kernel version, and I'm using the latest version.

As suggested I reduced the size of my log: https://0x0.st/HGh_.txt

Its much smaller now, it covers two boots: the first is rebooting with nouveau installed, the second is me booting to runlevel 3 to be able to use the console, because otherwise gdm started automatically and everything froze.

seth · 2024-01-27 21:49:32

ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (==) Using config file: "/etc/X11/xorg.conf"
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (==) Using config directory: "/etc/X11/xorg.conf.d"
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (==) Using system config directory "/usr/share/X11/xorg.conf.d"
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (==) ServerLayout "layout"
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (**) |-->Screen "nvidia" (0)
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (**) |   |-->Monitor "<default monitor>"
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (**) |   |-->Device "nvidia"
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (**) |   |-->GPUDevice "intel"
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (==) No monitor specified for screen "nvidia".
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]:         Using a default monitor configuration.
ene 27 18:21:10 tux /usr/lib/gdm-x-session[563]: (**) |-->Inactive Device "intel"

Post /etc/X11/xorg.conf and then move it away.

canolucas · 2024-01-27 22:05:15

Here is my xorg.conf, I tried both "nouveau" and "modesetting" for the Identifier "nvidia" (tried uninstalling xf86-video-nouveau as suggested in the wiki as it was last updated in 2021, the wiki suggests trying modesetting instead)

Section "ServerLayout"
Identifier "layout"
Screen 0 "nvidia"
Inactive "intel"
EndSection

Section "Device"
Identifier "nvidia"
Driver "nouveau" # I tried with both "nouveau" and "modesetting"
BusID "PCI:4:0:0"
EndSection

Section "Screen"
Identifier "nvidia"
Device "nvidia"
Option "AllowEmptyInitialConfiguration"
EndSection

Section "Device"
Identifier "intel"
Driver "modesetting"
EndSection

Section "Screen"
Identifier "intel"
Device "intel"
EndSection

Inside ./xorg.conf.d/ directory, I also have two files:

10-nvidia-drm-outputclass.conf

Section "OutputClass"
    Identifier "intel"
    MatchDriver "i915"
    Driver "modesetting"
EndSection

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nouveau"
    Driver "modesetting"  # I tried with both "nouveau" and "modesetting"
    Option "AllowEmptyInitialConfiguration"
    Option "PrimaryGPU" "yes"
#    ModulePath "/usr/lib/nvidia/xorg"
#    ModulePath "/usr/lib/xorg/modules"
EndSection

20-nvidia.conf

Section "OutputClass"
Identifier "nvidia"
MatchDriver "nouveau"
Driver "modesetting"  # I tried with both "nouveau" and "modesetting"
Option "AllowEmptyInitialConfiguration"
#ModulePath "/usr/lib/nvidia/xorg"
#ModulePath "/usr/lib/xorg/modules"
EndSection

@seth Do you want me to move all of these files away or only xorg.conf ?

Last edited by canolucas (2024-01-27 22:38:00)

seth · 2024-01-27 22:39:06

All of them, if you want to configure specific behavior, we'll add that afterwards.

canolucas · 2024-01-27 22:55:34

seth wrote:

All of them, if you want to configure specific behavior, we'll add that afterwards.

Awesome, so I just tried that. Here is the result, I actually tried bootiing two times:

First boot, with WaylandEnable=true in /etc/gdm/custom.conf
I get a white screen with a cursor. After some seconds I get a lot of flickering and weird colors, like a bugged game.
here is the journal log of that first boot: https://0x0.st/HGhn.txt

Second boot, with WaylandEnable=false, as I suspected gnome boots fine but uses intel integrated cpu chip for graphics
Intel® Core™ i7-4510U × 4
Intel® HD Graphics 4400 (HSW GT2)

seth · 2024-01-27 23:05:21

You're running the X11 session on the intel chip

ene 27 19:42:33 tux /usr/lib/gdm-x-session[568]: (EE) AIGLX error: dlopen of /usr/lib/dri/i965_dri.so failed (/usr/lib/dri/i965_dri.so: cannot open shared object file: No such file or directory)
ene 27 19:42:33 tux /usr/lib/gdm-x-session[568]: (EE) AIGLX error: unable to load driver i965
ene 27 19:42:34 tux /usr/lib/gdm-x-session[568]: (II) IGLX: Loaded and initialized swrast

get rid of every xf86-video-* package but maybe xf86-video-nouveau, but most importantly remove xf86-video-intel

There's actually no

ene 27 19:42:34 tux systemd[543]: GNOME Shell on Wayland was skipped because of an unmet condition check (ConditionEnvironment=XDG_SESSION_TYPE=wayland).

trace of a wayland session or GDM on wayland.

Also please return to loglevel=3 to keep the journal free of what's currently mostly spam.

Edit: if you find that the modesetting driver performs poorly on your HD 4400, you can also add /etc/X11/xorg.conf.d/20-intel.conf for xf86-video-intel

Section "Device"
        Identifier  "Intel Graphics"
        Driver      "intel"
        Option      "AccelMethod"    "sna"
        Option      "DRI"         "crocus"
EndSection

Last edited by seth (2024-01-27 23:10:25)

canolucas · 2024-01-28 00:51:43

got rid of every xf86-video-* package, still nouveau doesn't seem to work with my 520M. I tried every possible combination. It will always end up falling back to my intel cpu chip unless I explicitly specify nvidia official driver as detailed above and set Inactive "intel" in xorg.conf

I think I will wait for a newer version, maybe try again next year or so. I was just trying to make this nouveau driver work, but it looks like it needs much more stability right now.

Last edited by canolucas (2024-01-28 01:09:18)

seth · 2024-01-28 10:11:19

https://wiki.archlinux.org/title/NVIDIA_Optimus
https://wiki.archlinux.org/title/PRIME

How exactly do you intend to use the GPU?
Right now the only output connected is

ene 27 19:42:34 tux /usr/lib/gdm-x-session[568]: (II) intel(0): EDID vendor "AUO", prod id 17132

what means you'll *have* to use the IGP in some capacity, regardless which chip is used to render the source.

I'd however expect the binary driver to still peform much better in terms of game FPS, yes.

canolucas · 2024-01-28 14:35:15

@seth
Currently X11 works fine with the latest release of Nvidia's official drivers (version 390.157, released on 2022.11.22). While it is compatible for now, there is uncertainty about its future. Community-driven patching efforts accompany nearly every new Linux kernel release, as evident from the comments on the following AUR package page: nvidia-390xx-dkms. So the situation is not critical at the moment, but there's potential for escalation if the driver breaks without any viable resolution.

It's worth noting that this driver, being quite outdated, lacks support for Wayland and Vulkan. Although the closed-source Nvidia drivers shifted from EGLStreams to GBM at some point, the 390xx branch still uses EGLStreams. Wayland, however, requires GBM. As a result, my current reliance on Xorg is functional but limits future possibilities, especially regarding Vulkan support.

While Vulkan performs well with my integrated Intel chip, the performance falls short of what's achievable with the Nvidia dedicated GPU. Unfortunately, the current driver, which is at its end-of-life (EOL) stage, is not compatible.

With the news of NVK, the new Vulkan driver for nouveau, being accepted into Mesa and actively developed, I've attempted to transition to nouveau. However, achieving this switch seems unattainable at the moment.

Last edited by canolucas (2024-01-28 15:36:19)

xerxes_ · 2024-01-28 16:16:03

Don't change to nouveau now if you want Vulkan; it maybe works on nvidia gtx 20xx series and up now, but not lower. Also if you want change to nouveau try by startx/xinit method, not GDM, lightdm, etc.

seth · 2024-01-28 16:27:19

but it doesn't seem possible at the moment though

By what metric? I haven't seen any failures in your logs so far.

The typical approach would be to run the system on the IGP (also to avoid the framebuffer copying overhead and to save battery) and "prime-run superturboturkeypuncher³" on demand - nvidia or nouveau doesn't matter on that level (though only nouveau will let you do that on wayland)
You can also make the system to generally run on the nvidia chip, preferably by disabling the IGP in the BIOS/EFI (to save battery and avoid framebuffer copying lags) or otherwise by generally selecting the the nvidia chip and redirecting the output.

The only critical questions are:
1. does nouveau cause kernel crashes?
2. does the (verified) nouveau performance suck too much?

Edit: vulkan won't work w/ the 390xx drivers either, I'm not sure it ever will w/ nouveau on that HW

Last edited by seth (2024-01-28 16:28:16)

V1del · 2024-01-28 16:57:06

NVK is only going to work with GSP hardware so Turing and plus anyway currently. And yes Kepler was basically the first GPU with somewhat of a Vulkan support chip so you're out on that account as well.

canolucas · 2024-01-28 17:06:14

Sorry seth I couldn't even make it past gnome to check the performance. All I got is that white screen and then just random flickering colors all over the screen just like a bugged game. Alright, so it seems I'll never get vulkan support on my gpu anyways so nevermind feel free to close this thread if you need to.

UPDATE:
I found that according to this pdf page 19 and the card specifications page this card meets the conditions needed to support Vulkan however on the Vulkan Driver Support page the card is not listed.

Maybe some day they will add support for these mobile GPUs.. Who knows..
There are lots of laptops using these kind of mobile gpus right now. I know, the easy solution is to buy new hardware, maybe I will, but I know for sure that not everyone has that possibility.

Last edited by canolucas (2024-01-29 18:09:49)

Arch Linux

#1 2024-01-27 17:31:27

NVIDIA 520M + nouveau compatibility issue

#2 2024-01-27 17:35:34

Re: NVIDIA 520M + nouveau compatibility issue

#3 2024-01-27 17:39:32

Re: NVIDIA 520M + nouveau compatibility issue

#4 2024-01-27 20:57:15

Re: NVIDIA 520M + nouveau compatibility issue

#5 2024-01-27 21:44:43

Re: NVIDIA 520M + nouveau compatibility issue

#6 2024-01-27 21:49:32

Re: NVIDIA 520M + nouveau compatibility issue

#7 2024-01-27 22:05:15

Re: NVIDIA 520M + nouveau compatibility issue

#8 2024-01-27 22:39:06

Re: NVIDIA 520M + nouveau compatibility issue

#9 2024-01-27 22:55:34

Re: NVIDIA 520M + nouveau compatibility issue

#10 2024-01-27 23:05:21

Re: NVIDIA 520M + nouveau compatibility issue

#11 2024-01-28 00:51:43

Re: NVIDIA 520M + nouveau compatibility issue

#12 2024-01-28 10:11:19

Re: NVIDIA 520M + nouveau compatibility issue

#13 2024-01-28 14:35:15

Re: NVIDIA 520M + nouveau compatibility issue

#14 2024-01-28 16:16:03

Re: NVIDIA 520M + nouveau compatibility issue

#15 2024-01-28 16:27:19

Re: NVIDIA 520M + nouveau compatibility issue

#16 2024-01-28 16:57:06

Re: NVIDIA 520M + nouveau compatibility issue

#17 2024-01-28 17:06:14

Re: NVIDIA 520M + nouveau compatibility issue

Board footer