Package Details: nvidia-390xx-dkms 390.157-22

Git Clone URL: https://aur.archlinux.org/nvidia-390xx-utils.git (read-only, click to copy)
Package Base: nvidia-390xx-utils
Description: NVIDIA drivers - module sources
Upstream URL: https://www.nvidia.com/
Licenses: custom
Provides: NVIDIA-MODULE
Submitter: svenstaro
Maintainer: jonathon (vnctdj)
Last Packager: vnctdj
Votes: 61
Popularity: 0.26
First Submitted: 2020-03-11 17:29 (UTC)
Last Updated: 2026-05-02 21:19 (UTC)

Pinned Comments

vnctdj commented on 2025-01-24 07:37 (UTC)

Use this forum thread for discussion: https://bbs.archlinux.org/viewtopic.php?pid=1946926

jonathon commented on 2022-05-26 09:46 (UTC)

Please don't flag this package out-of-date unless a new version has been released by NVIDIA.

jonathon commented on 2021-12-26 22:44 (UTC) (edited on 2021-12-26 22:44 (UTC) by jonathon)

The DKMS package guidelines are explicit that linux-headers should not be a dependency of any DKMS package.

As a concrete example of why including that as a hard dependency is a bad idea, what happens when linux is not an installed kernel?

Latest Comments

1 2 3 4 5 6 .. 41 Next › Last »

bufferunderrun commented on 2026-05-04 23:02 (UTC)

There is always an option to rebuild the kernel.

twilight0 commented on 2026-05-04 11:59 (UTC) (edited on 2026-05-04 12:05 (UTC) by twilight0)

I got version mismatch for compilers today. make.log says kernel was built with gcc15 while latest packages provide gcc16. Initially installation failed so I had to type this command to rebuild dmks:

sudo IGNORE_CC_MISMATCH=1 dkms install nvidia/390.157 -k 6.18.26-1-cachyos-lts

Then this one because I have older lts kernel for backup:

sudo IGNORE_CC_MISMATCH=1 dkms install nvidia/390.157 -k 6.6.137-1-lts66

But still I am getting 640x480 resolution on 6.18 LTS kernel.

twilight0 commented on 2026-05-04 04:14 (UTC)

I guess I have to jump the wagon along with the rest of you for testing if necessary as I am not willing to replace my Nvidia GT555M based laptop anytime soon.

I 've already tried the open source driver* and I am frustruted it can't have frequency scaling, not to mention Xorg developers have abandoned any new stuff for it.

  • Tried the pstate/firmware and whatever chatgpt said it could help

canolucas commented on 2026-05-03 19:03 (UTC)

Thanks @drankinatty @bufferunderun @vnctdj and everyone who contributed. Looks like we make a pretty good team after all. If we keep this momentum going, maybe we can keep this deprecated driver alive through Linux 8.0, 9.0… who knows :)

drankinatty commented on 2026-05-03 01:28 (UTC)

Thank you @vnctdj! If it wasn't for @canolucas, and his understanding of the plumbing between conftest.sh, Kbuild and the generated headers, we would still be groping around in the dark. @bufferunderun helped carry the load as well with testing, review and feedback. A good collaborative effort. Let's hope 7.1 isn't as much "fun".

vnctdj commented on 2026-05-02 21:24 (UTC)

@drankinatty I just pushed your last patch, thanks a lot!

And thanks to canolucas for your thorough testing too, it wasn't easy this time...

drankinatty commented on 2026-05-02 20:25 (UTC) (edited on 2026-05-02 20:44 (UTC) by drankinatty)

Oh joy, gcc 16 is here -- Builds FINE -- no patch needed

I just saw gcc-16 in core. Has anyone tested how the driver builds against it? If history is a guide, the gcc-14.patch and gcc-15.patch suggested we would also need a gcc-16.patch.

Testing with both LTS and the 7.0 kernel, they build fine, no new patch required. Thankfully...

drankinatty commented on 2026-05-01 22:54 (UTC) (edited on 2026-05-01 23:04 (UTC) by drankinatty)

Whoop!

The NV_IS_EXPORT_SYMBOL_PRESENT_screen_info change was it. (that's one I could overlook 99 times out of 100 scanning the files). I can confirm success building against both 6.19 and 6.18-LTS kernels. I'll confirm the 7.0 build as soon as I update.

nvidia-390xx-utils kernel-7.0 patch Try 6 - hopefully final

Confirmed - Builds with Linux 7.0

Wow, this was a fun one.

bufferunderrun commented on 2026-05-01 22:30 (UTC)

@drankinatty I've had a similar thing going on earlier today, but canolucas' updated patch works now. It might be because of the conftest, your try-5 seems to have an older version of it.

canolucas commented on 2026-05-01 22:26 (UTC) (edited on 2026-05-01 22:39 (UTC) by canolucas)

Hey @drankinatty, sorry for the late reply.

There is almost no functional difference between using struct screen_info *si = &screen_info; and void *p = (void *)&screen_info;. I was testing different approaches and opted for the void pointer to force the compiler to ignore the source type, but both versions are effective for the test.

However, your version is actually superior because it validates two conditions at once:

  • Symbol Existence: Does screen_info exist in the global namespace?
  • Type Definition: Is the header containing the struct screen_info definition correctly included?

The void * approach only covers the first point. I definitely vote for switching to: struct screen_info *si = &screen_info;

The elif macro naming

Besides that detail, the most critical change was the macro name used in the #elif. I had to change it to: #elif defined(NV_IS_EXPORT_SYMBOL_PRESENT_screen_info) instead of #elif defined(NV_EXPORT_SYMBOL_SCREEN_INFO)

The reason is that NVIDIA's conftest.sh logic overrides the macro name you provide to follow its own internal naming convention (converting the test name to uppercase and adding prefixes).

How to verify the Macro Name

If you want to double-check the exact names generated by the conftest on your system, you can find the generated headers in the DKMS build directory or the source directory after an attempted build:

  • DKMS Path: /var/lib/dkms/nvidia/390.157/build/conftest/symbols.h

  • Source Path: src/NVIDIA-Linux-x86_64-390.157/kernel/conftest/symbols.h

Inside that file, you will see exactly which macros evaluated to 1 (success) or 0 (failure).

I hope that clears things up!

1 2 3 4 5 6 .. 41 Next › Last »