Package Details: opencl-nvidia-390xx 390.157-17

Git Clone URL: https://aur.archlinux.org/nvidia-390xx-utils.git (read-only, click to copy)
Package Base: nvidia-390xx-utils
Description: OpenCL implemention for NVIDIA
Upstream URL: https://www.nvidia.com/
Licenses: custom
Conflicts: opencl-nvidia
Provides: opencl-driver, opencl-nvidia
Submitter: svenstaro
Maintainer: jonathon (vnctdj)
Last Packager: vnctdj
Votes: 61
Popularity: 0.110555
First Submitted: 2020-03-11 17:29 (UTC)
Last Updated: 2025-06-12 22:18 (UTC)

Dependencies (2)

Required by (67)

Sources (20)

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 .. 34 Next › Last »

duht commented on 2025-09-02 12:40 (UTC)

@ventureo my laptop, an MSI GT780R, doesn't have an iGPU. The Intel graphics card is built into the i7 processor, but it's locked in the BIOS and can't be enabled. There's no NVIDIA Optimus, etc., and the laptop only runs on the dedicated GTX 560M. I've done some reading, and from what I understand, the patch was introduced in kernel 6.12 and rolled back in kernel 6.12.3 (or something like that). I recall having a similar problem a while back, and practically no one else here had it, and it resolved itself with the next minor kernel release. It's possible it happened with version 6.12- that would even be correct. Now Archlinux has reverted to this solution, which, as the author of the commit you posted a few comments below says, is very messy.

ventureo commented on 2025-09-02 10:44 (UTC)

@totofweb The reason why it may not affect you is that you are using it on desktop, while @duht uses a laptop that probably has an iGPU running simplefb, which creates a conflict with the NVIDIA driver.

ventureo commented on 2025-09-02 10:41 (UTC) (edited on 2025-09-02 10:41 (UTC) by ventureo)

@duht I looked a little deeper, and I think it’s about the patch for 6.12 and above. Patch requires nvidia-drm.modset=1 parameter for hot-plugging monitors [1] [2]. Which means that even with LTS you have to specify it, but without it driver is not fully functional. As for solutions of this problem remains: stay on the kernel version with patch, or roll back to a version even lower than the current LTS, which again causes the need to rebuild kernel. For some reason initcall_blacklist=simpledrm_platform_driver_init does not seem to work for 390.xx, as already written in the topic on forum.

[1] - https://aur.archlinux.org/cgit/aur.git/tree/kernel-6.12.patch?h=nvidia-390xx-utils#n63

[2] - https://gist.github.com/joanbm/a6d3f7f873a60dec0aa4a734c0f1d64e?permalink_comment_id=5254092#gistcomment-5254092

totofweb commented on 2025-09-01 20:10 (UTC) (edited on 2025-09-01 20:12 (UTC) by totofweb)

Indeed @duht, I confirm I had no issue while upgrading up to currently linux-6.16.4-arch1-1 on a desktop with 2 monitors on GeForce GTX 550 Ti. I do have the option nvidia-drm.modeset=1 set. I hope you can sort it out.

duht commented on 2025-09-01 13:12 (UTC)

Thanks, @ventureo, for your help. This could indeed be the cause of the problem. I tested your method on 6.16.4.zen1-1, and after adding the kernel parameter you provided, the system doesn't start at all. Grub stops at loading intrd disk... However, removing nvidia-drm.modeset=1 from the kernel parameters causes the xserver to load, but the HDMI-connected monitor isn't detected at all, and the laptop's LVDS screen is detected by xrandr as none-1, and the colors are strange, like 8-bit. For now, I'm sticking with 6.16.0. Interestingly, besides me and @Irving-1291, it seems no one else is having problems after Archlinux added the patch you mentioned.

ventureo commented on 2025-08-31 07:28 (UTC)

The reason why 6.16.1 broke old NVIDIA drivers is that in the Arch kernel was removed a patch https://github.com/archlinux/linux/commit/e5e142b09d1019863dada3c7860aeab5b2f56cdc. To workaround this you can try to pass initcall_blacklist=simpledrm_platform_driver_init in your kernel parameters or use LTS kernel.

duht commented on 2025-08-23 10:56 (UTC)

I checked and 6.16.1 has the same error. I have a laptop with an external monitor connected via HDMI, and Xorg is launched via startx. Disconnecting the monitor doesn't help. maybe running via startx means that the error doesn't occur for everyone? 6.16.0 works normally like all previous kernel versions. What changed in 6.16.1 that suddenly stopped working? Does anyone have any ideas?

aldolat commented on 2025-08-23 06:46 (UTC) (edited on 2025-08-23 07:11 (UTC) by aldolat)

No problem here upgrading from linux-6.16.1.arch1-1 to linux-6.16.2-arch1-1.

duht commented on 2025-08-22 23:53 (UTC)

I have exactly the same problem as @Irving-1291 with kernel 6.16.2-zen1-1. I haven't tested 6.16.1. 6.16.0 works fine. Does anyone have any ideas on how to solve this?

Irving-1291 commented on 2025-08-21 01:56 (UTC)

After updating to linux 6.16.1.arch1-1 Xorg stopped working. ~/.local/share/xorg/Xorg.0.log says that:

(EE) NVIDIA(GPU-0): Failed to acquire modesetting permission.
(EE) NVIDIA(0): Failing initialization of X screen 0
(II) UnloadModule: "nvidia"
(II) UnloadSubModule: "wfb"
(EE) Screen(s) found, but none have a usable configuration.
(EE)
Fatal server error:
(EE) no screens found

if I roll back to an older kernel, everything works just fine

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