Arch Linux User Repository

For the beginners in need of assistance, first take a look at this recommended guide https://github.com/korvahannu/arch-nvidia-drivers-installation-guide - maybe it helps to solve the issues your are having with this version of the driver.

Heads-up : the upcoming kernel 6.12 does not spare this version of the driver; I just tested the RC5 and DKMS is not able to build the kernel module.

If you feel motivated to help other, please try to find patches that might make it work; we will test them and include them in a new release of the package if they are reliable enough...

...

 CC [M]  /var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-fb.o
  CC [M]  /var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-modeset.o
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-drv.c:171:6: error: ‘const struct drm_mode_config_funcs’ has no member named ‘output_poll_changed’
  171 |     .output_poll_changed = nv_drm_output_poll_changed,
      |      ^~~~~~~~~~~~~~~~~~~
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-drv.c:171:28: error: initialization of ‘struct drm_atomic_state * (*)(struct drm_device *)’ from incompatible pointer type ‘void (*)(struct drm_device *)’ [-Wincompatible-pointer-types]
  171 |     .output_poll_changed = nv_drm_output_poll_changed,
      |                            ^~~~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-drv.c:171:28: note: (near initialization for ‘nv_mode_config_funcs.atomic_state_alloc’)
make[3]: *** [scripts/Makefile.build:229: /var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-drv.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-crtc.c: In function ‘plane_req_config_update’:
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-crtc.c:89:9: warning: unused variable ‘ret’ [-Wunused-variable]
   89 |     int ret = 0;
      |         ^~~
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-crtc.c: In function ‘nv_drm_plane_atomic_set_property’:
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-crtc.c:371:32: warning: unused variable ‘nv_drm_plane_state’ [-Wunused-variable]
  371 |     struct nv_drm_plane_state *nv_drm_plane_state =
      |                                ^~~~~~~~~~~~~~~~~~
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-modeset.c: In function ‘__will_generate_flip_event’:
/var/lib/dkms/nvidia/470.256.02/build/nvidia-drm/nvidia-drm-modeset.c:96:23: warning: unused variable ‘primary_plane’ [-Wunused-variable]
   96 |     struct drm_plane *primary_plane = crtc->primary;
      |                       ^~~~~~~~~~~~~
make[2]: *** [/usr/lib/modules/6.12.0-rc5-1-MANJARO/build/Makefile:1936: /var/lib/dkms/nvidia/470.256.02/build] Error 2
make[1]: *** [Makefile:224: __sub-make] Error 2
make[1]: Leaving directory '/usr/lib/modules/6.12.0-rc5-1-MANJARO/build'
make: *** [Makefile:80: modules] Error 2

judging from comments by SoftExpert and Alexey104, your best bet of running this stably and without many freezes are the LTS kernels. as of writing, there are 2, 6.1 and 6.6, that both see their support end at Dec 31st 2026. So unless things get bricked in other regions of your distro, in systemd for example, thats probably the EoL date for your old nvidia hardware then. I have since moved on to an older AMD gpu, and like SoftExpert, it has been a smooth and flawless experience so far.

@cotton: the only thing that matters is the version number of the kernel used. lts is just an older kernel version that was decided to receive longer support of certain security and other fixes than the others.

so in short: yea, until the support for any lts kernel with low enough version number runs out, you will be able to use this driver with those old kernels.

after that, it will be the same as using an old windows or android beyond support end: you will have the risk of being attacked through unfixed bugs and security issues if your device has any outside contact. for certain devices, that you use isolated and offline, that might not even be an issue.

So, will switching to nvidia-lts and linux-lts work, at least in the near term? Or is switching to nouveau the only option? [I'm using a GTX 650 Ti card]

Hi. In the latest update, nvidia-utils package enabled the use of nvidia_drm.modeset=1 and nvidia_drm.fbdev=1 by default. Although fbdev=1 option does not exist for the 470.xx driver branch, using modeset=1 by default can be very useful, because although Wayland does not work properly on this version, it is still required for PRIME configurations to work properly (see https://download.nvidia.com/XFree86/Linux-x86_64/470.256.02/README/randr14.html). So I think it would be useful to include this in this package at least through the /usr/lib/modprobe.d file installation.

@Scimmia: Indeed, this seems to be the end.

On the page Current graphics driver releases there is now a (*) next to the 470.239.06 (x86_64 175) - GKxxx “Kepler” GPUs line.

It was not there a few days ago.

They did not even bother to update the link - 470.256.02 is the latest (last ?) version of this driver generation.

What can I say, it was a wild ride ...

I made a big switch - I went with a Minisforum MS-A1 which has a Ryzen 8700G with an integrated Radeon 780M; I did not expect it to work so flawlessly ! Nothing to configure, everything recognized from the start, very good performance. Ah, and a reasonable price (sorry for the pub, I'm just sharing my experience).

According to https://nvidia.custhelp.com/app/answers/detail/a_id/5202 , support for the 470 series ended at the end of last month. That page hasn't been updated in a long time, though, does anyone have any newer information?

@Alexey104: The most frequent and frustrating one is occurring several times a day; all the Plasma panels and widgets are frozen; sometimes I'm in the middle of either listening music or in a Teams or Meet call; UI will not respond at all, often even the cursor will be frozen as well - but the sound will continue without interruption. It takes 20s, 30s or more until the notification "Desktop effects were restarted due to a graphics reset" is shown, and then everything is normal again until the next one which can be 50s away or a couple of hours ...

I noticed that using a combination of browsers (Firefox and Chromium-based) seems to increase the chances of having a graphics reset.

The other freeze is due to how NFS waiting time is handled in combination with systemd. I have the same setup of the NFS server and the same hardware for years and things started to go bad more than a year ago. Now it manifests at startup - frozen panels and widgets and then notifications of random file-systems that "are not responding", altough I can access their contents from the conole perfectly fine.

I do not have reboots, though.

@SoftExpert, May I ask which desktop freezes you are referring to? I am asking because I’ve been experiencing hard freezes with spontaneous reboots myself, starting from kernel 6.7 up to the current mainline (no problems with LTS, though), and I am interested in learning more about similar issues.

@drankinatty: We are lucky - for now: the official 6.11 (6.11.0) (official flavor, xanmod) is building fine the driver.

The desktop freeze is more and more frequent, though; I read that it has spread to more recent driver versions and it impacts more powerfull cards. I believe it is an unfortunate mix of kernel changes, resistance to these changes at the driver code plus some systemd quircks that are purposefully hard to isolate.

I think Nvidia is following other priorities - end-user sales are not bringing enough revenue to satisfy their appetite...

I will end up replacing my old and faithful laptop and I will stay away from Nvidia.

Minisforum here I go ... ;-)