Oh no, another Nvidia driver repository? Why? This repository reflects my personal view for the way the driver should be packaged for Fedora and CentOS/RHEL. It’s somewhat different from ELRepo repositories for RHEL/CentOS and from RPMFusion packages for Fedora.
Table of Contents
Repository installation
To install the repository on a supported Fedora distribution, run as root the following command:
dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.repo
To install the repository on CentOS/RHEL:
yum-config-manager --add-repo=https://negativo17.org/repos/epel-nvidia.repo
The Nvidia software packages are available for installation by default also in Gnome Software.
Please note that the driver will show up only if your system matches one of the PCI ID supported by the driver. Otherwise, only the other Nvidia programs (mostly for CUDA development) will show up in the software center.
What’s different?
First of all the packaging is a lot simplified; more stuff is compiled from source, smaller packages and more options. This packages try to comply as maximum to the Fedora Packaging Guidelines; which means they have debuginfo packages, default Fedora’s GCC compile time options (where possible) and standard locations for binaries, data and docs.
What follows below, is a detailed explanation of all the “differences” from the various Nvidia driver packages that I was able to spot on the web and a detailed description on how to install components, etc.
Nvidia drivers
Packaging
- nvidia-settings, nvidia-persistenced, nvidia-xconfig and nvidia-modprobe are compiled from source.
- All RPM filters except for GL and OpenCL libraries have been removed, so there is no weird dependency option in the SPEC file. RPM pulls in all correct requirements on its own. This is to avoid pulling in the Nvidia drivers instead of the Mesa libraries or in place of the new open source OpenCL support that’s in Fedora.
- Simplified packaging with much simpler and readable SPEC file.
- Dependency on libva-vdpau-driver. So in Totem, or any other libVA supported application you can benefit from VDPAU acceleration.
- Sources are generated with a script and inserted individually in the various packages; so it can be easily reproduced just by changing the version and rerunning the script.
nvidia-xconfigis not required on anything that uses the modular X.org directives, as it writes too much in the configuration file (keyboards, monitors, etc.) and the required entries should be written in separate configuration files under/etc/X11/xorg.conf.d. The package is still available as it’s required to speed up some configuration like multi-monitor setups with SLI Mosaic enabled from the command line, but not installed by default.- The NVIDIA OpenGL-based Framebuffer Capture (NvFBCOpenGL) libraries (NvFBC and NvIFR) are private APIs that are only available to NVIDIA approved partners for use in remote graphics scenarios (i.e. Steam In-Home Streaming hardware encoding); so they are packaged in another small package called
nvidia-driver-NvFBCOpenGL. - The
nvidia-settingspackage now builds the externallibXNVCtrl.solibrary that can be used to control the graphic cards through the NV-CONTROL extension. This library updates the old and obsolete one in Fedora. - The
nvidia-settingsbinary is compiled with GTK3 instead of GTK2 on Fedora and RHEL/CentOS 7+. - The driver can be installed separately from the
nvidia-settingsutility, so if you simply want a working driver and do not care about details, your experience should be as close as possible to the one with open source drivers.
Versioning
- ELRepo ships 32 bit compatibility libraries in a separate package with x86_64 as the architecture and “32bit” in the name. 32 bit libraries should be like in RPMFusion, with an i686 package installable in parallel with the x86_64 one. There are no other packages in the distribution that are built for x86_64, with “32bit” in their name that contain i686 binaries (!), so Nvidia drivers should not be an exception. So no separate “32bit.x86_64” package for 32 bit libraries also on CentOS/RHEL; just install
nvidia-driver-libs.i686. - Versions are not hidden; all packages have the same driver version.
- No alternatives system, only the latest version which integrates CUDA support is available. For older releases nouveau works great; and anything below a GeForce 8xxx it’s in my opinion too low end to play anything modern. And Quake 3 and Doom 3 work greatly with nouveau, so that’s not a case!
- The CentOS/RHEL repository contains the “Long Lived Branch version” where less changes occur; while Fedora repositories contains the “Short Lived Branch version”. Beta CentOS/RHEL and Fedora’s rawhide repositories will contain the “Beta Branch version”
CUDA support
- CUDA libraries/tools for the driver are split into subpackages. There’s no need to install all the CUDA libraries and tools on a system that has only one adapter and is used for occasional gaming or for simple office use. This can save ~120 MB worth of installed libraries. nvidia-persistenced falls in this category as it’s not needed on a normal laptop or gaming system.
- Complete packaged CUDA stack has been added for all supported distributions, all the packages provide/require/obsolete the relevant packages in the Nvidia CUDA repository; so you can enable this repository along with the official Nvidia CUDA one (x86_64 systems only).
Kernel modules
- Multiple choice of kernel module packages; akmod (RPMFusion) for Fedora and binary kmod (Kernel ABI whitelists) for CentOS/RHEL. In addition to this, on both distributions dkms packages are available. This way all cases and personal preferences are covered for both distributions.
- The Nvidia udev rules leverage
nvidia-modprobecommand in the system to create devices and set permissions even when the userspace libraries have not been loaded yet, covering the case of Wayland only sessions and compute only system without display userspace components installed. - The
nvidia-uvmmodule has a soft dependency on thenvidiamodule, making sure that these modules are not included in the initrd (thing that would happen by using systemd’s configuration (module-s-load.d). UDev rules make sure the module has proper permissions. - Choice of proprietary or open source license kernel modules.
Default configuration
- Dracut options are depending on the distribution; so no more “vga=normal is an obsolete option” at boot. Each distribution gets its own specific GRUB options for booting.
- 96 DPI is written in the default
xorg.confconfig file. Why? Gnome 3 by defaults hard-codes a 96×96 DPI resolution, most of the free drivers do (intel, nouveau, etc.) as the EDID is almost never reliable (please see the excellent Adam’s Jackson post where he explains this). As an example, if you install the Nvidia drivers on a RHEL/CentOS 6 laptop where you used to have nouveau installed (96 DPI hardcoded), the fonts gets 90% of the time supersize and ugly as Gnome 2 and the Nvidia driver do not hard-code 96 DPI like Gnome 3. - Make X.org NVIDIA Files section to be loaded latest in case there are other packages providing a custom Files section.
- Use new OutputClass directive on X.org server 1.16 (and later) to load the driver and do not rely on an edited
/etc/X11/xorg.conffile. This also removes editing of thexorg.conffile from the package scriptlets. This does not hardcode the 96 DPI resolution. - Add the
IgnoreABIdirective by default on Fedora rawhide builds.
Kernel modesetting and Wayland support
Kernel mode setting on the nvidia-drm module is enabled by default along with the console frame buffer driver.
Distribution and Nvidia driver version support
Here is a rundown of Nvidia supported drivers and options split by distribution. Basically, CentOS/RHEL will always get a Long Lived branch release if possible, Fedora always a Short Lived branch release, and unreleased distributions will always get a Beta driver.
| Operating system | CentOS / RHEL | Fedora | rawhide |
|---|---|---|---|
| Driver branch | Long Lived | Short Lived Long Lived | Short Lived Long Lived Beta |
| Video Codec SDK | Yes | Yes | Yes |
| Architectures: x86_64 aarch64 | Yes | Yes | Yes |
| Basic nvidia driver: nvidia-driver nvidia-driver-libs nvidia-libXNVCtrl nvidia-kmod-common | Yes | Yes | Yes |
| CUDA libraries and tools: libnvidia-ml nvidia-driver-cuda nvidia-driver-cuda-libs nvidia-persistenced | Yes | Yes | Yes |
| OpenGL Framebuffer Capture: libnvidia-fbc | Yes | Yes | Yes |
| Nvidia tools: nvidia-modprobe nvidia-settings nvidia-xconfig | Yes | Yes | Yes |
| Binary kernel modules (kABI): kmod-nvidia | Yes | No | No |
| DKMS kernel modules: dkms-nvidia | Yes | Yes | Yes |
| aKMOD kernel modules: akmod-nvidia | No | Yes | Yes |
| 32 bit compatibility on x86_64: libnvidia-ml nvidia-libXNVCtrl nvidia-driver-libs nvidia-driver-cuda-libs | Yes | Yes | Yes |
| VDPAU libraries | Yes | Yes | Yes |
| EGLStream-based Wayland external platform | Yes | Yes | Yes |
| GBM EGL external platform library | Yes | Yes | Yes |
Optimus laptops
The driver should install and operate cleanly whether you are installing it on a system which has one or more discrete Nvidia cards or an Optimus laptop with an Intel and a Nvidia card. Nothing to do to enable or configure Optimus.
This is up to the point that when the drivers are installed, you can even turn off Optimus on or off in your system Bios (if your laptop allows that) and the only difference you should see is that there’s an additional VGA card enabled in your system (check with lspci) and that the Nvidia control panel switches between a PRIME Display, like in this picture:
And a normal RandR managed one, like in this one:
Everything else should not be different from your normal experience.
Limitations with the Nvidia driver
The limitations are the same as provided by the Nvidia driver, this means that if you are running it on an Optimus laptop, the Intel card can never power off. Which means higher power consumption, unfortunately. If you have an Optimus laptop and absolutely need the proprietary drivers, my suggestion is still to disable Optimus in the Bios.
Limitations with the OSS stack
On the contrary, if you use the OSS stack (nouveau/intel) the second card can be powered off if there’s no application running on it or display directly connected to one of the card’s outputs. That’s the best reason to use the OSS drivers at all if you you’re not doing serious gaming or 3D work:
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :DynOff:0000:01:00.0
You also got the nifty selection menu about running your game on the discrete card on Gnome, which is really cool:
It will power up the video card just before launching the process. Launching a program through that menu entry is like starting it from the command line with the DRI_PRIME variable declared. For example, the same as above would be:
$ DRI_PRIME=1 quake3 & $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :DynPwr:0000:01:00.0
As you can see, the discrete video card is turned on. For Steam, you still need to edit each of your game to run on the Nvidia card:
SLI systems
SLI is now enabled by default with the Auto profile, there’s nothing to do if you have a SLI system. If you need any different SLI option (AA, SFR, etc.), just override it in X.org configuration files.
Nouveau fallback
With the new expanded OutputClass support for X, as carried out by Hans, it’s now super easy to switch to the OSS stack if the proprietary Nvidia driver somehow does not work. No user space component is touched, as soon as the Nvidia kernel module is not loaded (check on /sys/module/nvidia), the desktop starts with the normal OSS components you get with a normal installation. Thanks to all the work done on libglvnd, the libraries loaded are the correct one for the driver you are running.
This means that the performance of the Nvidia card would be abysmal, but still you would get a nice desktop and browser to Google around for answers on how to fix it :).
Sample installation
Here is an example. Let’s assume you have a freshly installed CentOS system with a recent Nvidia GPU and you want to:
- Install the driver for gaming
- Play Vulkan enabled games
- Want to be comfortable with the Nvidia control panel
- Play 32 bit games (Vulkan included) on a 64 bit system
- Play 32 bit Vulkan games on a 64 bit system
# yum install nvidia-driver nvidia-driver-libs.i686 Last metadata expiration check: 0:05:30 ago on Tue 05 Feb 2019 06:52:50 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: nvidia-driver x86_64 3:415.27-4.fc29 fedora-multimedia 2.4 M nvidia-driver-libs i686 3:415.27-4.fc29 fedora-multimedia 18 M Installing dependencies: akmod-nvidia x86_64 3:415.27-1.fc29 fedora-multimedia 10 M nvidia-driver-cuda-libs x86_64 3:415.27-4.fc29 fedora-multimedia 25 M nvidia-driver-libs x86_64 3:415.27-4.fc29 fedora-multimedia 34 M nvidia-kmod-common noarch 3:415.27-1.fc29 fedora-multimedia 10 k akmods noarch 0.5.6-17.fc29 updates 22 k egl-wayland x86_64 1.1.1-3.fc29 updates 29 k kernel-devel x86_64 4.20.6-200.fc29 updates 13 M mesa-libEGL i686 18.2.8-1.fc29 updates 112 k mesa-libgbm i686 18.2.8-1.fc29 updates 39 k libglvnd-egl i686 1:1.1.0-2.fc29 fedora 45 k libglvnd-gles i686 1:1.1.0-2.fc29 fedora 32 k libglvnd-opengl i686 1:1.1.0-2.fc29 fedora 37 k libglvnd-opengl x86_64 1:1.1.0-2.fc29 fedora 39 k libva-vdpau-driver x86_64 0.7.4-22.fc29 fedora 60 k libwayland-server i686 1.16.0-1.fc29 fedora 38 k Transaction Summary ================================================================================ Install 17 Packages Total download size: 103 M Installed size: 385 M Is this ok [y/N]:
As you can see, this system has akmod enabled kernel modules and libraries for running 32 bit applications. The amount of data to download for the drivers is really small compared to packages that contain CUDA libraries and tools.
Package installation
If you are booting the system in UEFI mode; as a prerequisite to installing any external module (not built into the kernel package), you have to disable UEFI Secure Boot in the system configuration. All modules contained in the kernel package are signed with keys that are generated during build and deleted when packaging. If you want to preserve Secure Boot, you need to sign the modules yourself and import the keys into your hardware module. Doing so is out of scope here; if you need a decent guide just follow Red Hat’s guide for signing kernel modules.
First of all remove all the Nvidia drivers you might have on your system due to RPMFusion, ELRepo, or the Nvidia CUDA repository. This is usually accomplished with the following root command:
yum -y remove *nvidia*
Then, to install the Nvidia driver and its control panel utility in CentOS/RHEL with the binary kABI (Kernel ABI whitelist) module (this is the default on CentOS/RHEL), perform the following command:
yum -y install nvidia-driver nvidia-settings
To do the same in Fedora, using akmod modules, perform the following command:
dnf -y install nvidia-driver nvidia-settings
Specific driver installations
For both Fedora and CentOS/RHEL distributions it’s possible to install additional packages and / or variant of the basic kernel modules. This paragraph contains some examples. Make sure you have the EPEL repository enabled if you plan to use DKMS modules on CentOS/RHEL.
akmod kernel module variant (Fedora):
dnf -y install nvidia-driver akmod-nvidia
DKMS kernel module variant (Fedora/CentOS/RHEL):
yum/dnf -y install nvidia-driver dkms-nvidia
To add 32 bit libraries on a 64 bit system (for games or applications like Steam):
yum/dnf -y install nvidia-driver-libs.i686
Proprietary and open source kernel modules
Since almost a year, the Nvidia driver ships with two different implementations of the kernel modules, one proprietary and one open source. The open source one as of drivers 545.x is now considered beta quality also for the workstations, so it seems a good moment to start shipping it.
The open source one is supposed to be the only one that will be kept in the future, but at the moment both are available and both differ in terms of functionality. You can read about the main differences in terms of functionality and what chips they support in the official documentation.
I did not want to introduce another variation of the kernel modules beside akmods, kABI and DKMS, this would have created even more confusion and lots of dependencies in the SPEC files for the variations. The new akmod and DKMS packages ship both sources (MIT/GPL and proprietary kernel modules) and allow you to switch between one or the other through a configuration file.
Considering that in the long run only the open source variant will remain, I wanted to make this as transparent as possible for the users. Basically, if you don’t care and just want something that works, nothing has changed for you.
The two sources get referenced as they are referenced inside the Nvidia run file, namely “kernel” for the original proprietary kernel modules and “kernel-open” for the new open source variation.
The following instructions show you how to switch between one implementation or the other.
DKMS
Check which version you have installed:
# modinfo -l nvidia
NVIDIAChange the type of modules you want to use and trigger a rebuild and a reinstall:
# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --forceNow check again the license and you should see that it has changed to MIT/GPL:
# modinfo -l nvidia
Dual MIT/GPL
# rebootTo switch back, change the configuration again and then trigger the same process for rebuilding installing:
# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --force
# rebootakmods
Check which version you have installed:
# modinfo -l nvidia
NVIDIAChange the type of modules you want to use and trigger a rebuild and a reinstall:
# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# akmods --rebuildNow check again the license and you should see that it has changed to MIT/GPL:
# modinfo -l nvidia
Dual MIT/GPL
# rebootTo switch back, change the configuration again and then trigger the same process for rebuilding installing:
# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# akmods --rebuild
# rebootAdditional driver configuration to your system
To add additional configuration to your system, just create the /etc/X11/xorg.conf file. For example:
Section "Device"
Identifier "Device0"
Driver "nvidia"
Option "NoLogo" "true"
Option "DPI" "96 x 96"
Option "SLI" "Auto"
Option "nvidiaXineramaInfoOrder" "DFP-0"
Option "metamodes" "GPU-a493fbbb-7d76-86a2-8764-d76d487a75a7.DVI-I-1: nvidia-auto-select +0+0, GPU-c02960a4-be28-d5ce-8b02-be04b5e2550b.DVI-I-1: nvidia-auto-select +1680+0"
Option "BaseMosaic" "on"
EndSection
In this example we have 2 video cards with one monitor each, so we enabled SLI, Base Mosaic to have multi monitor support on SLI and make a layout with the second GPU monitor on the right of the first one. Also, we fix the DPI to 96×96, which is the hardcoded default in Gnome and in Open Source drivers.
Configuration for CUDA only systems
Your system might only be used for CUDA development and not require the X server to be running the DDX driver at all, so you might want to tweak the configuration a bit to make the system load (for example) the Intel driver as the main display and just the Nvidia driver for GPU workloads. In this case you have two options.
Option with only CUDA components installed
To install just the CUDA components of the driver and not the OpenGL libraries and all files required by the DDX part of the driver, proceed to install as follows:
# yum install nvidia-driver-cuda Last metadata expiration check: 0:22:51 ago on Tue 05 Feb 2019 06:52:50 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: nvidia-driver-cuda x86_64 3:415.27-4.fc29 fedora-multimedia 308 k Installing dependencies: akmod-nvidia x86_64 3:415.27-1.fc29 fedora-multimedia 10 M nvidia-driver-NVML x86_64 3:415.27-4.fc29 fedora-multimedia 457 k nvidia-driver-cuda-libs x86_64 3:415.27-4.fc29 fedora-multimedia 25 M nvidia-kmod-common noarch 3:415.27-1.fc29 fedora-multimedia 10 k nvidia-persistenced x86_64 3:415.27-2.fc29 fedora-multimedia 40 k akmods noarch 0.5.6-17.fc29 updates 22 k kernel-devel x86_64 4.20.6-200.fc29 updates 13 M Transaction Summary ================================================================================ Install 8 Packages Total download size: 49 M Installed size: 168 M Is this ok [y/N]:
As you can see, there are no components providing OpenGL or DDX drivers installed on the system. This will not use any X (or Wayland) configuration compared to what has been installed by default on your system.
On top of this, you can still select what kind of kernel modules you want ot have installed (kABI, akmods and dkms).
The device files are created by the udev rules that call the nvidia-modprobe command, it contains a SUID binary that creates the device files and set the appropriate permissions. The same binary is called directly by Nvidia libraries when accessing a user space component that would require device files access:
$ for i in $(rpm -ql nvidia-driver-libs.x86_64 nvidia-driver-cuda-libs.x86_64 | grep \.so); do strings $i | grep nvidia-modprobe > /dev/null && echo $i done /usr/lib64/gbm/nvidia-drm_gbm.so /usr/lib64/libnvidia-allocator.so.1 /usr/lib64/libnvidia-allocator.so.545.29.02 /usr/lib64/libnvidia-api.so.1 /usr/lib64/libnvidia-cfg.so.1 /usr/lib64/libnvidia-cfg.so.545.29.02 /usr/lib64/libnvidia-eglcore.so.545.29.02 /usr/lib64/libnvidia-glcore.so.545.29.02 /usr/lib64/libnvidia-glsi.so.545.29.02 /usr/lib64/vdpau/libvdpau_nvidia.so.1 /usr/lib64/vdpau/libvdpau_nvidia.so.545.29.02 /usr/lib64/libcuda.so /usr/lib64/libcuda.so.1 /usr/lib64/libcuda.so.545.29.02 /usr/lib64/libnvcuvid.so /usr/lib64/libnvcuvid.so.1 /usr/lib64/libnvcuvid.so.545.29.02 /usr/lib64/libnvidia-opencl.so.1 /usr/lib64/libnvidia-opencl.so.545.29.02
This requires some testing and adjustments with specifics to your setup, but is definitely possible to use the integrated Intel card and or rely on a system without X installed to run the CUDA components.
CUDA
Packaging
- Previously in the repository was included the GPU Deployment kit. This was constructed with NVML (NVIDIA Management Library) headers, docs and samples from a separate tarball. The separate tarball was using a different version number than the drivers and was packaged in the
nvidia-driver-NVMLandnvidia-driver-NVML-develpackages. Starting from CUDA version 8, the NVML header is provided by a CUDA subpackage (cuda-nvml-devel) and no longer provided as part of the GPU Deployment kit. - Included is also the Video Codec SDK (Decoder/Encoder) headers, docs and code samples. Again, this uses a different version than the drivers.
- All the libraries are split into subpackages, much like in the original Nvidia CUDA repository. This allows you to install and build software relying on specific components without the need to install all the CUDA toolkit just to satisfy a library dependency. Also, for the same reason, static libraries have been included in each respective
staticsubpackage. - In addition to the libraries bundled in the CUDA toolkit, also the cuDNN library for distributed neural networks is included in the repository. See the table below for details.
Distribution and CUDA version support
All the currently supported Red Hat Enterprise Linux versions (including rebuilds and similar forks – CentOS Stream, AlmaLinux, RockyLinux, EuroLinux, etc.) and Fedora versions are available.
In case of yet unsupported compilers in recent distributions, a compatibility cuda-gcc package is available that brings the distribution to a working level with nvcc.
By installing the cuda-gcc package, a variable is loaded automatically that adds the appropriate NVCC options to override the default system GCC when compiling:
$ cat /etc/profile.d/cuda-gcc.sh
export NVCC_PREPEND_FLAGS='-ccbin /usr/bin/cuda'CUDA installations
To install just a runtime CUDA support (required for running CUDA enabled programs), without DDX drivers:
yum -y install cuda nvidia-driver-cuda
To just install packages required for enabling CUDA development:
yum -y install cuda-devel
Or if you just want to enable everything:
dnf/yum -y install nvidia-driver nvidia-driver-cuda cuda-devel
A couple of examples. Just the basic tools:
# yum install cuda Last metadata expiration check: 0:30:55 ago on Tue 05 Feb 2019 06:52:50 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size
================================================================================ Installing: cuda x86_64 1:10.0.130-1.fc29 fedora-multimedia 17 M Installing dependencies: cuda-libs x86_64 1:10.0.130-1.fc29 fedora-multimedia 8.6 M nvidia-driver-cuda-libs x86_64 3:415.27-4.fc29 fedora-multimedia 25 M Transaction Summary ================================================================================ Install 3 Packages Total download size: 51 M Installed size: 178 M Is this ok [y/N]:
The basic tools along with all the libraries (note that the NVML headers are included):
# yum install cuda-devel Last metadata expiration check: 0:35:09 ago on Tue 05 Feb 2019 06:52:50 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: cuda-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 1.6 M Installing dependencies: cuda x86_64 1:10.0.130-1.fc29 fedora-multimedia 17 M cuda-cublas x86_64 1:10.0.130-1.fc29 fedora-multimedia 31 M cuda-cublas-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 32 M cuda-cudart x86_64 1:10.0.130-1.fc29 fedora-multimedia 135 k cuda-cudart-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 533 k cuda-cufft x86_64 1:10.0.130-1.fc29 fedora-multimedia 64 M cuda-cufft-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 127 M cuda-cupti x86_64 1:10.0.130-1.fc29 fedora-multimedia 1.4 M cuda-cupti-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 226 k cuda-curand x86_64 1:10.0.130-1.fc29 fedora-multimedia 38 M cuda-curand-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 61 M cuda-cusolver x86_64 1:10.0.130-1.fc29 fedora-multimedia 40 M cuda-cusolver-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 15 M cuda-cusparse x86_64 1:10.0.130-1.fc29 fedora-multimedia 27 M cuda-cusparse-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 28 M cuda-libs x86_64 1:10.0.130-1.fc29 fedora-multimedia 8.6 M cuda-npp-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 58 M cuda-nvgraph x86_64 1:10.0.130-1.fc29 fedora-multimedia 68 M cuda-nvgraph-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 13 k cuda-nvjpeg x86_64 1:10.0.130-1.fc29 fedora-multimedia 372 k cuda-nvjpeg-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 14 k cuda-nvml-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 53 k cuda-nvrtc x86_64 1:10.0.130-1.fc29 fedora-multimedia 6.3 M cuda-nvrtc-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 15 k cuda-nvtx x86_64 1:10.0.130-1.fc29 fedora-multimedia 33 k cuda-nvtx-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 41 k nvidia-driver-NVML x86_64 3:415.27-4.fc29 fedora-multimedia 457 k nvidia-driver-cuda-libs x86_64 3:415.27-4.fc29 fedora-multimedia 25 M Transaction Summary ================================================================================ Install 29 Packages Total download size: 650 M Installed size: 1.6 G Is this ok [y/N]:
An example where your CUDA application just uses the CUDA Runtime API and not the kernel runtime:
$ sudo dnf install cuda-cudart Last metadata expiration check: 0:13:10 ago on Sun Oct 23 13:11:01 2016. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: cuda-cudart x86_64 1:8.0.44-4.fc24 fedora-nvidia 131 k Transaction Summary ================================================================================ Install 1 Package Total size: 131 k Installed size: 536 k Is this ok [y/N]:
This will avoid you pulling in all the libraries as before just because you need a single library. This is useful for example for programs that leverage just some part of the CUDA toolkit, like the Nvidia Performance Primitives for image and signal processing in FFmpeg, and similar things.
Bugs
Just open an issue to the specific package on GitHub.
Hi Everyone,
I noticed a more recent problem with a consistent stuttering across my entire system using the latest Nvidia drivers (384.90) and the latest kernel on Fedora 26 (4.13.4-200). This problem didn’t exhibit itself a couple of weeks ago, although I’m not sure what package updates actually caused it.
The stuttering can be seen scrolling on a webpage, watching a youtube video, or even just typing. It occurs about every 5-10 seconds.
I tried to reinstall the older version of the nvidia drivers (384.69) by downgrading using dnf, but I ran into some problems. I wasn’t able to get the kernel module to rebuild, so the next time I logged into Xorg I believe I was actually using Nouveau.
I noticed in the Nvidia changelog for 384.90 Nvidia specifically mentions a fix for stuttering, so perhaps this is related?
I’m using a GTX 1060 with a Ryzen 1700, so my system specs are fairly good.
Thanks!
On Fedora 27 with GTX 1050 Ti GDM and Wayland sessions are causing 100% CPU usage and animations are stuttering (LLVMpipe I guess).
More details:
$ ls -al /dev/nvidia*
crw-rw-rw-. 1 root root 195, 0 10-07 12:38 /dev/nvidia0
crw-rw-rw-. 1 root root 195, 255 10-07 12:38 /dev/nvidiactl
crw-rw-rw-. 1 root root 195, 254 10-07 12:38 /dev/nvidia-modeset
crw-rw-rw-. 1 root root 241, 0 10-07 12:38 /dev/nvidia-uvm
crw-rw-rw-. 1 root root 241, 1 10-07 12:38 /dev/nvidia-uvm-tools
$ cat /proc/devices | grep nvidia
195 nvidia-frontend
241 nvidia-uvm
242 nvidia-nvlink
$ dnf list installed | grep nvidia
akmod-nvidia.x86_64 2:387.12-1.fc27 @fedora-nvidia
kmod-nvidia-4.13.4-300.fc27.x86_64.x86_64
kmod-nvidia-4.13.5-300.fc27.x86_64.x86_64
nvidia-driver.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-driver-NVML.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-driver-NvFBCOpenGL.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-driver-cuda.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-driver-cuda-libs.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-driver-libs.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-libXNVCtrl.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-modprobe.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-persistenced.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-settings.x86_64 2:387.12-1.fc27 @fedora-nvidia
$ uname -r
4.13.5-300.fc27.x86_64
dmesg https://pastebin.com/LCpn6WtV
Xorg.0.log https://pastebin.com/PNnVpBm2
Forgot to add that logging to X11 session instead of Wayland workarounds issue.
Hi !
By the past your driver was perfect with our studio setup, we do 3d rendering with cuda cards.
I can’t tell you when (a change this year ?) but now your nvidia-drivers-cuda doesn’t work anymore for cuda computing, the nvidia drivers work but cuda don’t… I’ve installed multiple times “yum -y install nvidia-driver-cuda nvidia-settings”
To solve that I actually installed on our computers the packages from elrepo witch solves the problem but I have a question, can I leave elrepo AND your multimedia repo on ? should I blacklist kmod-nvidia ? your ffmpeg and mpv build are so usefull 😉
I don’t think you can use them at the same time but I might be wrong. What is the issue exactly?
Can you see if with the drivers here you have all devices correctly created?
If not, can you try to install
nvidia-modprobe, reboot, and check again?Thanks,
–Simone
Hi, sorry for the late reply.
About the driver not working, I reported you back cuda wasn’t working but in fact that was the whole nvidia driver who wasn’t working, nvidia-settings in gnome reports no nvidia driversI think there is a fall back to nouveau…
On Centos latest (7.4) I don’t get why the Elrepo driver works and your don’t…
I tried on a blank disk a F26 Install and I can repro 100% what’s hapenning on CentOs, nvidia-modrobe don’t help. The same goes for F27
Do you know an equivalent of Elrepo nvidia drivers for Fedora ?
Hello, trying to install nvidia drivers in a VM with VT-d PCI passthrough of the nvidia card. On the host nouveau module is disabled and the VM sees the card. Also the nvidia_drm module is successfully loaded.
When I run
$ sudo nvidia-smiI’m gettingUnable to determine the device handle for GPU 0000:00:09.0: Unknown Error. And in console I’m gettingNVRM: RmInitAdapter failed! (0x23:0x56:469)
NVRM: rm_init_adapter failed for device bearing minor number 0
NVRM: RmInitAdapter failed! (0x23:0x56:469)
NVRM: rm_init_adapter failed for device bearing minor number 0
This is with akmod-nvidia-384.90-1.fc26.x86_64 but same also happens when I install directly with nvidia installer. Any ideas whether this can be fixed?
With Fedora 27 nvidia driver 384.69-1.fc27 and kernel 4.13.2-300.fc27.x86_64 i got with akmod an error and its unable to compile the driver 2017/09/20 00:40:28 akmodsbuild: MODPOST 4 modules
2017/09/20 00:40:28 akmodsbuild: FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol ‘lockdep_init_map’
2017/09/20 00:40:28 akmodsbuild: make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
2017/09/20 00:40:28 akmodsbuild: make[1]: *** [Makefile:1520: modules] Error 2
2017/09/20 00:40:28 akmodsbuild: make[1]: Leaving directory ‘/usr/src/kernels/4.13.2-300.fc27.x86_64’
The F27 kernels have debug build enabled by mistake. It’s already fixed in the kernel rpm spec file, but not rebuilt and released.
If you can’t wait – clone https://src.fedoraproject.org/rpms/kernel/branch/f27 and rebuild locally.
Hi Friends:
Unfortunately I’m booted from Windows on my multiboot laptop, so I don’t have access to all of the information that I would normally post.
After a ‘dnf -y update’ updated my nvidia collection of RPM to version — 384.69-1.fc25.x86_64 — I get the below segmentation fault. Everything was working fine for many months before that update. I’m running the latest Fedora 25 kernel, which is: 4.12.11-200.fc25.x86_64. Note that booting to a previous kernel doesn’t fix the issue.
I wish I could do a rpm -qa | egrep ‘nvidia|xorg‘ to add more information, but I am not booted into Linux to do that. The problem could be with the nvidia driver and/or with the xorg RPMs.
See below. Any ideas? Thank you in advance!
X.Org X Server 1.19.3
Release Date: 2017-03-15
X Protocol Version 11, Revision 0
Build Operating System: 4.9.3-200.fc25.x86_64
Current Operating System: Linux y700 4.12.11-200.fc25.x86_64 #1 SMP Fri Sep 8 11:44:51 UTC 2017 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.12.11-200.fc25.x86_64 root=/dev/sdb1 ro gfxpayload=vga=normal quiet rd.driver.blacklist=nouveau net.ifnames=0 biosdevname=0 LANG=en_US.UTF-8
Build Date: 15 March 2017 06:37:12PM
Build ID: xorg-x11-server 1.19.3-1.fc25
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 13 23:08:47 2017
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
(EE) Backtrace:
(EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59ea19]
(EE) 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7fb88acbf61f]
(EE) 2: /usr/lib64/xorg/modules/libglamoregl.so (glamor_init+0x16b) [0x7fb88442951b]
(EE) 3: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (_init+0x39c1) [0x7fb8885bec91]
(EE) 4: /usr/libexec/Xorg (AddGPUScreen+0xf0) [0x437480]
(EE) 5: /usr/libexec/Xorg (InitOutput+0x287) [0x47cf87]
(EE) 6: /usr/libexec/Xorg (InitFonts+0x216) [0x43aea6]
(EE) 7: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7fb88a908431]
(EE) 8: /usr/libexec/Xorg (_start+0x2a) [0x424d5a]
(EE)
(EE) Segmentation fault at address 0x43ba50
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
(EE)
Please consult the Fedora Project support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: unexpected signal 2
Firstly, thank you for this driver packaging. Brilliant.
I’m using releases from NVIDIA’s Vulkan dev branch, and would prefer packages and not a .run file, for whose contents i am not convinced i will ever be able to really remove, or reliably update against.
I have little RPM packaging chops, but if there were “shoulders to stand on”, like a packaging framework that knows what to do with a .run file, i might be able to dedicate enough time and succeed. Can any of the work going into these repos be shared?
Cheers
In my use case, on CentOS 7, might be to take from Fedora, which has Vulkan, if i’m assuming the specifics i need are being included in what’s in Fedora. I don’t feel i can assume that.
But, really, this is all too vague. Here.
https://github.com/ValveSoftware/SteamVR-for-Linux
referring to
https://developer.nvidia.com/vulkan-driver
referring to
https://developer.nvidia.com/3812613-linux-64bit
You might want to check if you can rebuild the latest Vulkan to 1.0.57 on RHEL 7:
https://koji.fedoraproject.org/koji/packageinfo?packageID=23126
Then the various SPEC files are here:
https://github.com/negativo17?utf8=%E2%9C%93&q=nvidia&type=&language=
To prepare the various tarballs just use the script in the nvidia-driver package:
https://github.com/negativo17/nvidia-driver/blob/master/nvidia-generate-tarballs.sh
Based on this driver. I have successfully build and install nvidia-docker! https://github.com/NVIDIA/nvidia-docker/wiki/Installation, with make rpm and rpm -i dist/nvidia-docker-1.0.1-1.x86_64.rpm
Even more importantly, this driver (version 384.69) helps to get NVIDIA GTX 1080 Ti GPU runs on my CentOS 7.3 server. I spent two nights trying to get it working. driver version 375.26 (current official download) does not work for 1080 Ti, it works for GTX 970.
Thanks a lot!!!
I can just probably integrate that into the repository. Will look into it if it is worth or not.
Hello and, as always, thanks for the great work.
Yesterday night I upgraded my Fedora 26 to the latest version of your drivers and Gnome is now running on Wayland! So the support has finally landed? Do we have to configure something?
Thanks,
Bauno
Not really. You need a custom mutter:
https://copr.fedorainfracloud.org/coprs/mvicomoya/mutter-eglstream/
Follow the instructions there if you want to enable Wayland on GNOME 3. Support for it has been enabled out of the box with Fedora 27 (drivers + mutter 3.25+)
Hmmm…
loginctl
SESSION UID USER SEAT TTY
c1 42 gdm seat0 /dev/tty1
2 1000 bauno seat0 /dev/tty2
loginctl show-session 2 -p Type
Type=wayland
rpm -q mutter
mutter-3.24.4-1.fc26.x86_64
Weird?
B.
Ok, I’m a moro 🙂
For some reason, the driver update re-enabled nouveau removeing the blacklist line in grub.cfg…
Now it’s back to normal. Sorry for the confusion.
B.
OpenCL not working
Hello, I installed this nvidia drivers on fresh EL7.4, on optimus laptop. Everythings works fine, except for OpenCL. I also installed packages opencl-filesystem and ocl-icd but it doesnt seem to help. I cant get it working in any application.
for example here is the output from darktable:
darktable -d opencl
…
[opencl_init] opencl related configuration options:
[opencl_init]
[opencl_init] opencl: 1
[opencl_init] opencl_library: ”
[opencl_init] opencl_memory_requirement: 768
[opencl_init] opencl_memory_headroom: 300
[opencl_init] opencl_device_priority: ‘/!0,//‘
[opencl_init] opencl_size_roundup: 16
[opencl_init] opencl_async_pixelpipe: 0
[opencl_init] opencl_synch_cache: 0
[opencl_init] opencl_number_event_handles: 25
[opencl_init] opencl_micro_nap: 1000
[opencl_init] opencl_use_pinned_memory: 0
[opencl_init] opencl_use_cpu_devices: 0
[opencl_init] opencl_avoid_atomics: 0
[opencl_init] opencl_omit_whitebalance: 0
[opencl_init]
[opencl_init] could not find opencl runtime library ‘libOpenCL’
[opencl_init] could not find opencl runtime library ‘libOpenCL.so’
[opencl_init] found opencl runtime library ‘libOpenCL.so.1’
[opencl_init] opencl library ‘libOpenCL.so.1’ found on your system and loaded
[opencl_init] could not get platforms: -1001
[opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
[opencl_init] initial status of opencl enabled flag is OFF.
If you need any more info or testing please let me know 🙂
Have a nice day
Opened this as issue on github: https://github.com/negativo17/nvidia-driver/issues/31
Any idea why I’m getting
h264_nvenc @ 0x251644dca0] Cannot init CUDA
[h264_nvenc @ 0x251644dca0] cuCtxPushCurrent failed
I’ve installed nvenc, cuda, nvidia drivers and nothing…
nvencare just headers, required if you need to compile some software that uses NVENC. Make sure to havenvidia-drivers-cudainstalled.Yes, it is installed:
↪ rpm -qa | grep nvidia
nvidia-driver-devel-384.59-4.fc26.x86_64
nvidia-driver-NvFBCOpenGL-384.59-4.fc26.x86_64
nvidia-driver-NVML-384.59-4.fc26.x86_64
nvidia-persistenced-384.59-1.fc26.x86_64
nvidia-driver-384.59-4.fc26.x86_64
nvidia-libXNVCtrl-384.59-1.fc26.x86_64
nvidia-driver-cuda-libs-384.59-4.fc26.x86_64
dkms-nvidia-384.59-1.fc26.x86_64
nvidia-driver-libs-384.59-4.fc26.x86_64
nvidia-settings-384.59-1.fc26.x86_64
nvidia-driver-cuda-384.59-4.fc26.x86_64
↪ lsmod | grep nv
nvidia_drm 45056 3
nvidia_modeset 843776 9 nvidia_drm
nvidia_uvm 675840 0
nvidia 13037568 411 nvidia_modeset,nvidia_uvm
drm_kms_helper 155648 2 i915,nvidia_drm
drm 348160 6 i915,nvidia_drm,drm_kms_helper
I face the same issue. I do not use nvenc that often so cannot say what could possibly break CUDA. It used to work in F25 when I already was using negativo17 repository. Also at least a fortnight ago after I upgraded F25 to F26 and installed all the required packages, like nvidia-driver-cuda, which somehow got removed during upgrade, CUDA was working fine (I just quickly verified it using cuda-z). However after installing new kernel 4.12.8 I do see in logs a slight different order of nvidia related entires, some HDA NVidia HDMIs are before the usual loading of nvidia modules. Would be really bizarre that some soundcard loading stuff forbids proper CUDA initialization. Strangely enough when I booted older kernel 4.12.5 the order of logs is now the same as in 4.12.8.
Hum, my environment is exactly the same of yours, f26 and kernel 4.12.8.
I checked it a bit further and it seems it is some permission issue. Runnig nvenc from ffmpeg or cuda-z as root is working ok. I am not sure what should be the correct ownership of nvidia devices but I changed them from root to video group and it is now working for my user as well. Seems that the udev rules are somewhat incomplete.
I spoke too soon. This is not the ownership issue. CUDA starts working when it is first used by root, then it works for all users despite the root:root ownership of nvidia devices. Maybe some initialization/locking issue then?
I believe the problem has to do in some way with the lack of some relevant root files that CUDA need to load at boot time.
The udev rules have hardcoded major number for the UVM devices. I created an issue
https://github.com/negativo17/nvidia-driver/issues/29
Hopefully it could be fixed soon.
Thank you very much for creating the issue in Github. Will look at it immediately.
F25 has a problem (Dell T7600) with the latest kernel and nvidia driver.
1) 4.11.12-200.fc25.x86_64 always loads nouveau
4.11.11-200.fc25.x86_64 works fine
2) nvidia-driver-2:384.59-3.fc25.x86_64
Looks like a gnome shell library related issue?
[ 520.923115] gnome-shell[26091]: segfault at 48 ip 00007fe4043918a0 sp 00007ffda0ca2198 error 4 in libmutter-cogl.so[7fe404358000+a7000]
[ 524.449936] gnome-shell[26208]: segfault at 48 ip 00007fac73e7f8a0 sp 00007fff4fbb3bf8 error 4 in libmutter-cogl.so[7fac73e46000+a7000]
[ 524.497533] gnome-session-f[26343]: segfault at 0 ip 00007f3f5caff869 sp 00007ffc602e7d80 error 4 in libgtk-3.so.0.2200.17[7f3f5c820000+6eb000]
[ 525.281125] nvidia-modeset: Freed GPU:0 (GPU-41da5200-fbd1-51a7-03ad-1b7bf1a9ba8b) @ PCI:0000:05:00.0
[ 525.833486] nvidia-modeset: Allocated GPU:0 (GPU-41da5200-fbd1-51a7-03ad-1b7bf1a9ba8b) @ PCI:0000:05:00.0
Are you attempting to use Wayland? Mutter in Fedora 26 does not support EGLstream yet, please use the X session.
Fresh F26 install… X server does not start. (This used to work on
F25, but some driver/kernel update broke it in the last 2 months;
after lots of troubleshooting I decided to do a fresh install, but
alas the problem persists.) Any pointers would be GREATLY
appreciated.
[The comment system seems to be eating my posts… Trying again in
smaller chunks, I apologize in advance if duplicates appear…]
Info follows:
[smaller post == success]
X.Org X Server 1.19.3
Release Date: 2017-03-15
X Protocol Version 11, Revision 0
Build Operating System: 4.10.6-200.fc25.x86_64
Current Operating System: Linux xx.xxxx.xxx 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.12.5-300.fc26.x86_64 root=/dev/mapper/fedora_xi–pb-root ro rd.lvm.lv=fedora_xi-pb/root rd.lvm.lv=fedora/swap quiet LANG=en_US.UTF-8 rd.driver.blacklist=nouveau 3
Build Date: 23 April 2017 11:51:31PM
Build ID: xorg-x11-server 1.19.3-4.fc26
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (–) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: “/var/log/Xorg.0.log”, Time: Wed Aug 16 13:25:53 2017
(==) Using config directory: “/etc/X11/xorg.conf.d”
(==) Using system config directory “/usr/share/X11/xorg.conf.d”
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult the Fedora Project support
at http://wiki.x.org
for help.
(EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
/var/log/Xorg.0.log [edited for brevity]
X.Org X Server 1.19.3
[ 416.265] Kernel command line: BOOT_IMAGE=/vmlinuz-4.12.5-300.fc26.x86_64 root=/dev/mapper/fedora_xi–pb-root ro rd.lvm.lv=fedora_xi-pb/root rd.lvm.lv=fedora/swap quiet LANG=en_US.UTF-8 rd.driver.blacklist=nouveau 3
[ 416.326] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 416.327] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0
[ 416.327] (II) xfree86: Adding drm device (/dev/dri/card1)
[ 416.328] (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 12 paused 0
[ 416.330] () OutputClass “nvidia” setting /dev/dri/card0 as PrimaryGPU
[ 416.332] (–) PCI:*(0:2:0:0) 10de:1022:10de:0982 rev 161, Mem @ 0xfa000000/16777216, 0xe0000000/268435456, 0xf0000000/33554432, BIOS @ 0x????????/524288
[ 416.332] (–) PCI: (0:4:0:0) 10de:13c2:1462:3171 rev 161, Mem @ 0xf8000000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x0000e000/128, BIOS @ 0x????????/131072
[ 416.658] (II) Applying OutputClass “nvidia” to /dev/dri/card0
[ 416.769] (II) Applying OutputClass “nvidia” to /dev/dri/card1
[ 416.989] (II) LoadModule: “nvidia”
[ 417.114] (II) NVIDIA dlloader X Driver 384.59 Wed Jul 19 23:14:49 PDT 2017
[ 417.127] (II) NVIDIA(0): Creating default Display subsection in Screen section
[ 417.128] (II) Applying OutputClass “nvidia” options to /dev/dri/card0
[ 417.128] () NVIDIA(0): Option “SLI” “Auto”
[ 417.128] () NVIDIA(0): Option “BaseMosaic” “on”
[ 417.128] () NVIDIA(0): Option “AllowEmptyInitialConfiguration”
[ 417.129] () NVIDIA(0): NVIDIA SLI auto-select rendering option.
[ 417.129] () NVIDIA(0): Enabling 2D acceleration
[ 419.089] (EE) NVIDIA(GPU-0): Failed to find a valid Base Mosaic configuration.
[ 419.089] (EE) NVIDIA(GPU-0): Invalid Base Mosaic configuration 1 of 1:
[ 419.089] (EE) NVIDIA(GPU-0): GPUs:
[ 419.089] (EE) NVIDIA(GPU-0): 1) NVIDIA GPU at PCI:2:0:0
[ 419.089] (EE) NVIDIA(GPU-0): 2) NVIDIA GPU at PCI:4:0:0
[ 419.089] (EE) NVIDIA(GPU-0): Errors:
[ 419.089] (EE) NVIDIA(GPU-0): – The video link was not detected
[ 419.089] (EE) NVIDIA(GPU-0): – Unsupported GPU
[ 419.089] (EE) NVIDIA(GPU-0): – Chipset not approved for SLI
[ 419.089] (EE) NVIDIA(GPU-0): – GPU PCI IDs do not match
[ 419.089] (WW) NVIDIA(GPU-0): Failed to find a valid Base Mosaic configuration for the
[ 419.089] (WW) NVIDIA(GPU-0): NVIDIA graphics device PCI:2:0:0. Please see Chapter 28:
[ 419.089] (WW) NVIDIA(GPU-0): Configuring SLI and Multi-GPU FrameRendering in the README
[ 419.089] (WW) NVIDIA(GPU-0): for troubleshooting suggestions.
[ 419.193] (EE) NVIDIA(GPU-0): Only one GPU will be used for this X screen.
[ 420.374] (WW) NVIDIA(GPU-0): No 3D engine available.
[ 420.374] (EE) NVIDIA(GPU-0): Failed to select a 2D engine.
[ 420.474] (EE) NVIDIA(0): Failing initialization of X screen 0
[ 420.474] (II) UnloadModule: “nvidia”
[ 420.474] (II) UnloadSubModule: “wfb”
[ 420.474] (II) UnloadSubModule: “fb”
[ 420.474] (EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
[ 420.474] (EE) no screens found(EE)
[ 420.475] (EE) Server terminated with error (1). Closing log file.
The issue is that it’s trying to use the Tesla K20C as the primary display adapter. You need to force it into starting on the other one by writing some X.org configuration.
You could also edit
/etc/X11/xorg.conf.d/10-nvidia.confand see if commenting all the “Option” works.To create your custom X.org config file, just copy that to
/etc/X11/xorg.confand edit it there.Thanks for the reply… I’m still having problems; what option/setting do I need in order to change the selection of the Tesla card:
(**) OutputClass “nvidia” setting /dev/dri/card0 as PrimaryGPU
to the GeForce GTX 970 card
(**) OutputClass “nvidia” setting /dev/dri/card1 as PrimaryGPU
I tried adding
Section “Device”
Identifier “Device1”
Driver “nvidia”
VendorName “NVIDIA Corporation”
BusID “PCI:4:0:0”
Screen 0
EndSection
Section “Screen”
Identifier “Screen0”
Device “Device1”
GPUDevice “Device1”
EndSection
Section “ServerLayout”
Identifier “Layout0”
Screen 0 “Screen0”
EndSection
but no dice. 🙁
Upgrading to 2:384.59-3.fc26 from 2:384.59-2.fc26 never reaches the GDM login screen and keeps resetting/cycling the monitors. GeForce GTX 550 Ti/PCIe/SSE2 Fedora 26. It was necessary to downgrade.
Testing update that was not supposed to be pushed (mistake). Rolled back on 2:384.59-4. Thanks.
The -4 roll is working fine, thank you for the quick attention:)
I’m getting the same issue on 2:384.59-3.fc25 so is this not fixed for Fedora 25?
I figured out what I did to keep the nvidia driver from your repo from working on fedora 26 and how to get it working again on my system, but I don’t understand why. I broke it by changing the default plymouth theme from charge to details so that I could see the detailed text boot log and then I rebuilt initrd with:
plymouth-set-default-theme details –rebuild-initrd
And I figured out that I could fix it with:
plymouth-set-default-theme solar –rebuild-initrd
Although the solar animations don’t animate quite correctly and the flares jump around so I will probably set it back to the default “charge” theme.
What dependencies did I break for the nvidia driver by changing the pymouth theme? Perhaps this dependency should be be mentioned in your excellent installation instructions above?
Also, what is the recommended method to switch between intel and nvidia drivers on fedora for those of us who have laptops which hide the BIOS settings to enable and disable the nvidia graphics hardware? Is an additional grub entry the best way to do it?
Thank you for your packaging work on this driver!
Looking for some more permanent solution to select nvidia/nouveau/intel on boot, that would respect kernel updates, I created the following solution. It will add nvidia/nouveau boot option, where intel is default. Not very grub polite but it works well.
In all modprobe files disable ‘blacklist’ options for nvidia/nouveau, it will depend on command line options.
2. In nvidia-fallback.service add ‘-b’ as in this line, so nouveau is not loaded if only intel is required:
ExecStart=-/sbin/modprobe -b nouveau
3. In /etc/default/grub:
GRUB_CMDLINE_LINUX_OPTION[0]=”nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off”
GRUB_CMDLINE_LINUX_OPTION[1]=”rd.driver.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_kms_helper modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_kms_helper”
GRUB_CMDLINE_LINUX_DEFAULT=”${GRUB_CMDLINE_LINUX_OPTION[0]} ${GRUB_CMDLINE_LINUX_OPTION[1]}”
declare -A GRUB_CMDLINE_LINUX_ALTERNATIVE
GRUB_CMDLINE_LINUX_ALTERNATIVE[nvidia]=”${GRUB_CMDLINE_LINUX_OPTION[0]}”
GRUB_CMDLINE_LINUX_ALTERNATIVE[nouveau]=”${GRUB_CMDLINE_LINUX_OPTION[1]}”
export GRUB_CMDLINE_LINUX_ALTERNATIVES=$(declare -p GRUB_CMDLINE_LINUX_ALTERNATIVE)
4. Add this executable file as /etc/grub.d/11_linux_alternative:
#! /bin/sh
set -e
GRUB_DISABLE_SUBMENU=”n”
eval $GRUB_CMDLINE_LINUX_ALTERNATIVES
for alternative in ${!GRUB_CMDLINE_LINUX_ALTERNATIVE[]}; do
GRUB_DISTRIBUTOR=”$alternative”
GRUB_CMDLINE_LINUX_DEFAULT=”${GRUB_CMDLINE_LINUX_ALTERNATIVE[$alternative]}”
. ${0%/}/10_linux
done
I have a Dell Precision 5520 with Optimus (Intel/Nvidia GPUs) installed. I have used both of the following to try to install the drivers, but GDM doesn’t seem to be coming up on this Fedora 26 machine:
dnf -y install nvidia-driver nvidia-settings kernel-devel
and
dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686
(I did a “dnf remove *nvidia*”, of course, in between the two installations to clean things up).
I see the console systemd startup messages after I get the usual Fedora logo at startup, but the startup process never transitions to GDM, even though it does try to start GDM.
It looks like some things are happy:
dkms status
nvidia, 384.59, 4.11.11-300.fc26.x86_64, x86_64: installed
but I also see the following from dmesg:
[ 410.396375] gnome-shell[2210]: segfault at 28 ip 00007fefc6bcd7e4 sp 00007ffc5a19c3e0 error 4 in libmutter-0.so.0.0.0[7fefc6b7e000+13a000]
From journalctl -r:
systemd-coredump[2219]: Process 2210 (gnome-shell) of user 42 dumped core.
Stack trace of thread 2210:#0 0x00007fefc6bcd7e4 center_pointer (libmutter-0.so.0)
#1 0x00007fefc6be1ad9 meta_backend_x11_post_init (libmutter-0.so.0)
#2 0x00007fefc6be2b19 meta_backend_x11_cm_post_init (libmutter-0.so.0)
#3 0x00007fefc6c0c586 meta_init (libmutter-0.so.0)
#4 0x0000555fd6e041aa main (gnome-shell)
#5 0x00007fefc06294da __libc_start_main (libc.so.6)
#6 0x0000555fd6e045ba _start (gnome-shell)
Stack trace of thread 2215:
#0 0x00007fefc09ebf94 recvmsg (libpthread.so.0)
#1 0x00007fefc3cc647c g_socket_receive_message_with_timeout (libgio-2.0.so.0)
#2 0x00007fefc3cc6a66 g_socket_receive_message (libgio-2.0.so.0)
#3 0x00007fefc3d14974 _g_socket_read_with_control_messages_ready (libgio-2.0.so.0)
#4 0x00007fefc3cc3121 socket_source_dispatch (libgio-2.0.so.0)
#5 0x00007fefc21ef247 g_main_context_dispatch (libglib-2.0.so.0)
#6 0x00007fefc21ef5e8 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
#7 0x00007fefc21ef902 g_main_loop_run (libglib-2.0.so.0)
#8 0x00007fefc3d14cb6 gdbus_shared_thread_func (libgio-2.0.so.0)
#9 0x00007fefc2216536 g_thread_proxy (libglib-2.0.so.0)
#10 0x00007fefc09e136d start_thread (libpthread.so.0)
#11 0x00007fefc0719b8f __clone (libc.so.6)
Stack trace of thread 2211:
#0 0x00007fefc070da9d poll (libc.so.6)
#1 0x00007fefc21ef569 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
#2 0x00007fefc21ef67c g_main_context_iteration (libglib-2.0.so.0)
#3 0x00007fefc21ef6c1 glib_worker_main (libglib-2.0.so.0)
#4 0x00007fefc2216536 g_thread_proxy (libglib-2.0.so.0)
#5 0x00007fefc09e136d start_thread (libpthread.so.0)
#6 0x00007fefc0719b8f __clone (libc.so.6)
Stack trace of thread 2216:
#0 0x00007fefc0714529 syscall (libc.so.6)
#1 0x00007fefc22346fa g_cond_wait_until (libglib-2.0.so.0)
#2 0x00007fefc21c3b31 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0)
#3 0x00007fefc2216ed4 g_thread_pool_thread_proxy (libglib-2.0.so.0)
#4 0x00007fefc2216536 g_thread_proxy (libglib-2.0.so.0)
#5 0x00007fefc09e136d start_thread (libpthread.so.0)
#6 0x00007fefc0719b8f __clone (libc.so.6)
Stack trace of thread 2217:
#0 0x00007fefc070da9d poll (libc.so.6)
#1 0x00007fefc21ef569 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
#2 0x00007fefc21ef67c g_main_context_iteration (libglib-2.0.so.0)
#3 0x00007fefa1319f3d dconf_gdbus_worker_thread (libdconfsettings.so)
#4 0x00007fefc2216536 g_thread_proxy (libglib-2.0.so.0)
#5 0x00007fefc09e136d start_thread (libpthread.so.0)
#6 0x00007fefc0719b8f __clone (libc.so.6)
Aug 09 09:35:43 gnome-session[2189]: Unable to init server: Could not connect: Connection refused
Aug 09 09:35:43 spice-vdagent[2277]: Cannot access vdagent virtio channel /dev/virtio-ports/com.redhat.spice.0
Aug 09 09:35:43 gnome-session-binary[2189]: WARNING: App ‘org.gnome.Shell.desktop’ respawning too quickly
Aug 09 09:35:43 gnome-session-binary[2189]: Unrecoverable failure in required component org.gnome.Shell.desktop
Aug 09 09:35:43 gnome-session-binary[2189]: WARNING: Application ‘org.gnome.Shell.desktop’ killed by signal 11
Aug 09 09:35:43 gnome-session[2189]: gnome-session-binary[2189]: WARNING: App ‘org.gnome.Shell.desktop’ respawning too quickly
Aug 09 09:35:43 gnome-session[2189]: gnome-session-binary[2189]: WARNING: Application ‘org.gnome.Shell.desktop’ killed by signal 11
I have tried disabling Wayland for GDM by modifying “/etc/gdm/custom.conf” to have “WaylandEnable=false” (uncommented). The behavior is different–I see the Fedora bootup logo on the screen and don’t see the console messages at all. I don’t see the gnome-shell segfault messages via dmesg, but I see similar messages to the journalctl -r output above (gnome-shell is still crashing).
If I remove the nvidia packages using “dnf remove *nvidia*”, I can get back to using the Nouveau drivers just fine.
Any thoughts on how to resolve this?
I figured out how to resolve the problem. As noted in https://wiki.debian.org/InstallingDebianOn/Dell/Precision%205520%20%28Laptop%29/jessie, the Linux kernel command line should not include
nomodeset, but mine did. I removednomodesetfrom/etc/sysconfig/gruband then rangrub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg(See Fedora Wiki: Grub 2) to update GRUB 2. With this set properly, GDM comes up without crashing and I can use the laptop just fine with both Gnome 3 (using the Intel drivers and Wayland) and Plasma/KDE (using the proprietary Nvidia drivers and X).Thanks for all the great work to package the drivers and associated software!
The packages do not use
nomodesetas boot parameter, it actually removes it. Look for%global _dracutoptsand%global _dracutopts_rmin the SPEC file: https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.specI have a fresh F26 install on a ASUS F556U notebook. lspci says:
VGA compatible controller: Intel Corporation Device 5916 (rev 02)
3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
$ rpm -qa nvidia*
nvidia-driver-libs-384.59-1.fc26.i686
nvidia-driver-384.59-1.fc26.x86_64
nvidia-settings-384.59-1.fc26.x86_64
nvidia-driver-libs-384.59-1.fc26.x86_64
nvidia-driver-cuda-libs-384.59-1.fc26.x86_64
nvidia-driver-cuda-384.59-1.fc26.x86_64
nvidia-driver-NVML-384.59-1.fc26.x86_64
nvidia-libXNVCtrl-384.59-1.fc26.x86_64
nvidia-persistenced-384.59-1.fc26.x86_64
$ dkms status
nvidia, 384.59, 4.11.11-300.fc26.x86_64, x86_64: installed
But the driver doesn’t seem to load properly:
$ glxinfo | grep -i string
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.5
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.0 Mesa 17.1.5
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.1.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
Am I doing something wrong?
Can you try running
lspci -k? It tells you which driver is attached to which device.[…]
00:02.0 VGA compatible controller: Intel Corporation Device 5916 (rev 02)
Subsystem: ASUSTeK Computer Inc. Device 1490
Kernel driver in use: i915
Kernel modules: i915
[…]
01:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device 1490
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia
[…]
And BTW: GRUB does have this in the config: rd.driver.blacklist=nouveau
I’m assuming you are using X.org and not Wayland. Do you have any custom X.org configuration? You should not have anything, just use the package X.org configuartion files as they are.
I haven’t done anything to X.org config.
$ loginctl show-session 2 -p Type
Type=wayland
I have several repos activated in my install (most notably UnitedRMPS). I will install F26 again from scratch, and try it with your repo only. Will report after.
Before reinstalling everything, can you just trying login with an X.org session instead of Wayland?
Sorry, too late. This time, I did install only the basic stuff:
$ sudo dnf install nvidia-settings kernel-devel dkms-nvidia
But otherwise ended with exactly the same results. When I log in with X.org, though:
$ glxinfo | grep -e string
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 940MX/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 384.59
OpenGL core profile shading language version string: 4.50 NVIDIA
OpenGL version string: 4.5.0 NVIDIA 384.59
OpenGL shading language version string: 4.50 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 384.59
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
What is “same result”? In the previous comment you typed about Intel being used and not Nvidia, this is no longer the case. So is it working?
With X.org yes, but with Wayland it’s still the same – i.e. Intel works, Nvidia doesn’t. glxinfo output looks the same for Wayland, but in X.org it shows what I pasted earlier.
Hi, on F26 after update to latest driver and reboot Cinnamon is crashing and failing into safe mode. Removing dkms-nvidia and installing it back fixes the problem.
I see the same thing – it broke within the last week while it had been working fine. When this driver is installed and plasma is selected from gdm, it tries to start X11 and goes back to gdm. Failed to initialize the nvidia kernel module. I can confirm it was working fine as I ran benchmarks before it broke recently.
I forgot to mention that I also tried uninstalling this driver and installing the one from rpmfusion and got exactly the same result when I try to start KDE. Here is a pastebin of the Xorg log file: https://pastebin.com/W7PRreSa The system is fedora 26 with all updates installed. It did work fine until very recently.
for i in $(rpm -ql nvidia-driver-libs.x86_64); do strings $i | grep nvidia-modprobe > /dev/null && echo $i; done
/usr/lib64/libnvidia-cfg.so.1
/usr/lib64/libnvidia-cfg.so.384.59
/usr/lib64/libnvidia-eglcore.so.384.59
/usr/lib64/libnvidia-glcore.so.384.59
/usr/lib64/libnvidia-glsi.so.384.59
/usr/lib64/vdpau/libvdpau_nvidia.so.1
/usr/lib64/vdpau/libvdpau_nvidia.so.384.59
It’s probably this issue due to a kernel change:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4609
Patch for the non-repo nvidia driver: https://devtalk.nvidia.com/default/topic/1019362/linux/fully-working-patch-for-nvidia-driver-340-102-compiler-installer-file-and-linux-kernel-4-12/
That’s for driver 340.102, which is a legacy version I’m no longer shipping.
There’s now three new driver versions released since 381.22. How to I get at a newer 38x driver while using negativo17?
Actually there is one: https://devtalk.nvidia.com/default/topic/1019588/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-384-59-long-lived-branch-release-/
All branches will go to 348.59, which has been posted 16 hours ago. I will make some tests and then post the packages online.
Super fast work! Thanks.
I finally hope to get PrimeSync to work. 🙂
Many thanks! The update came fast!
Was hoping the latest with all the improvements would solve the corrupted display on resume from suspend that Fedora 25 and 26 has but it didn’t 🙁
I already know its either the Nvidia driver, gpu, or Fedora as this happens with the same gpu in two completely different computers. Though the installation of Fedora is dirty and I may do one more test with a clean Fedora install on the second computer but not holding out any hope.
So… a clean install of Fedora 26 then the negativo17 Nvidia supplied driver actually worked! (No more resume from suspend issues. Unfortunately, no idea where the problem was. Maybe something left over from Fedora 25 or previous official Nvidia driver install.)
And to get Steam working it requires an additional change Nvidia related change via terminal after the negativo17 supplied driver is installed and possibly a reboot (which may break nvidia-settings as that no longer starts). There’s so much fun with Fedora lol
Hey, thanks a lot. My fedora 26 is working fine with more performance after installation. I installed with:
How can I test my drivers installation correctly?
Well, if it doesn’t crash, that’s a good indication that you are not using Nouveau on a recent Nvidia card.
or any log will tell you which drivers are you using.
I just installed the drivers on Fedora 26, but I can’t get to the login screen. I erased rhgb and quiet from grub, and the last message was [OK] Starting Gnome Display Manager. When I checked /var/log/X.org.0.log, it says
LoadModule: “ramdac”
Module “ramdac” already built-in
NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the system’s kernel log for additional error messages […]
When I did rpm -qa nvidia kernel* | sort, the output told me I have kernel, kernel-core, kernel-devel and kernel-modules for 4.11.10-300.fc26.x86_64 and a few older ones.
Make sure the dkms module is built:
If not:
$ dkms status
nvidia, 381.22, 4.11.10-300.fc26.x86_64, x86_64: installedError! Could not locate dkms.conf file.
File: does not exist.
$ sudo dkms install nvidia/381.22
Module nvidia/381.22 already installed on kernel 4.11.10-300.fc26.x86_64/x86_64
How should I fix this?
Nothing to fix, just add “sudo” also at the previous command.
thank you, it works now. I also had to re-disable secure boot.
This has been a problem for me since F25, but someone might be able to help me. My AVR is giving out wrong EDID, so I use Option “UseEDID” “FALSE”, and set the “metamodes” in xorg.conf:
Section “Screen”
Identifier “Screen0”
Device “Device0”
Monitor “Monitor0”
Option “metamodes” “DFP-1: 1920×1080 +0+0”
DefaultDepth 24
SubSection “Display”
Depth 24
EndSubSection
EndSection
However, I’m not able to manually set the “metamodes”. I get this in my Xorg.0.log:
[ 51.877] () NVIDIA(0): NVIDIA SLI auto-select rendering option.
[ 51.877] () NVIDIA(0): Option “UseEDID” “FALSE”
[ 51.878] () NVIDIA(0): Option “MetaModes” “DFP-1: 1920×1080 +0+0”
[ 51.878] () NVIDIA(0): Enabling 2D acceleration
[ 51.878] (**) NVIDIA(0): Ignoring EDIDs
[ 51.886] (WW) NVIDIA(0): Failed to initialize Base Mosaic! Reason: Only one GPU
[ 51.886] (WW) NVIDIA(0): detected. Only one GPU will be used for this X screen.
[ 52.536] (–) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:2:0:0
[ 52.536] (–) NVIDIA(0): CRT-0
[ 52.536] (–) NVIDIA(0): CRT-1
[ 52.536] (–) NVIDIA(0): DFP-0
[ 52.536] (–) NVIDIA(0): DFP-1 (boot)
[ 52.537] (II) NVIDIA(0): NVIDIA GPU GeForce GT 430 (GF108) at PCI:2:0:0 (GPU-0)
[ 52.537] (–) NVIDIA(0): Memory: 1048576 kBytes
[ 52.537] (–) NVIDIA(0): VideoBIOS: 70.08.29.00.01
[ 52.537] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[ 52.540] (–) NVIDIA(GPU-0): CRT-0: disconnected
[ 52.540] (–) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
[ 52.540] (–) NVIDIA(GPU-0):
[ 52.541] (–) NVIDIA(GPU-0): CRT-1: disconnected
[ 52.541] (–) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
[ 52.541] (–) NVIDIA(GPU-0):
[ 52.543] (–) NVIDIA(GPU-0): DFP-0: disconnected
[ 52.543] (–) NVIDIA(GPU-0): DFP-0: Internal TMDS
[ 52.543] (–) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
[ 52.543] (–) NVIDIA(GPU-0):
[ 52.543] (–) NVIDIA(GPU-0): DFP-1: connected
[ 52.543] (–) NVIDIA(GPU-0): DFP-1: Internal TMDS
[ 52.543] (–) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock
[ 52.543] (–) NVIDIA(GPU-0):
[ 52.544] (WW) NVIDIA(0): No valid modes for “DFP-1:1920×1080+0+0”; removing.
[ 52.544] (WW) NVIDIA(0):
[ 52.544] (WW) NVIDIA(0): Unable to validate any modes; falling back to the default mode
[ 52.544] (WW) NVIDIA(0): “nvidia-auto-select”.
[ 52.544] (WW) NVIDIA(0):
[ 52.547] (II) NVIDIA(0): Validated MetaModes:
[ 52.548] (II) NVIDIA(0): “DFP-1:nvidia-auto-select”
[ 52.548] (II) NVIDIA(0): Virtual screen size determined to be 640 x 480
Now, I can only see 640×480 resolution on my big TV which makes me sad. Is there anyone who can help me figure out why the metamode won’t take? I’m suspecting the wrong pixel clock from the AVR. If that’s true, is there option to override the pixel clock too?
Thanks!
Hello Slanesh
I successfully installed your repo in fedora 26 and nvidia proprietary drivers in my optimus laptop. I was
able to run Gnome in X11 and Wayland mode. But I dislike gnome and try to install other window
managers, like XFCE, Matte, but all of them do not run with your setup. I login in lightdm and
the screen stays black without showing nothing. It only works if I remove 10-nvidia.conf and
runs in intel driver. Do you know what is happening or how to debug why this is happening? Any
help is welcome.
I remember having seen a bug on bugzilla.redhat.com about lightdm and other login managers not playing nicely with Optimus setups, but I can’t find it, sorry.
In fact, the problem is not with lightdm, but with WINDOW MANAGER, like matte and xfce.
Have you ever managed to resolve the issue with black screen?
I’m on fedora 26 with xfce and after installing this driver, i can login into Gnome and everything is ok, but with xfce i only get black screen.
DESTRONIJE, I cannot solve the problem, unfortunately. I switched back to bumblebee until this be solved. I cannot find any tip about this.
I struggle to compile the cuda samples from below amidst looking for cuda-install-samples-8.0.sh in vain. Any advice? Appreciate!
dnf -y install cuda nvidia-driver-cuda cuda-devel cuda-samples
uname -r
4.11.9-300.fc26.x86_64
cd /usr/share/cuda/samples/
make
make[1]: Entering directory ‘/usr/share/cuda/samples/0_Simple/UnifiedMemoryStreams’
/usr/bin/nvcc –include-path /usr/include/cuda -ccbin g++ -I../../common/inc -m64 -Xcompiler -fopenmp -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_60,code=compute_60 -o UnifiedMemoryStreams.o -c UnifiedMemoryStreams.cu
/usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h(444): error: identifier “nullptr” is undefined
…
You need to use GCC 5.3 to use CUDA on Fedora. Last GCC supported version by CUDA 8 is 5.3. Look for
compat-gcc*packages in the same repository.Thanks for the hint! However, I seem to still be missing s.th. see below. Any ideas?
[root@localhost samples]# dnf install compat-gcc-53
[root@localhost samples]# make
make[1]: Entering directory ‘/usr/share/cuda/samples/0_Simple/UnifiedMemoryStreams’
/usr/bin/nvcc –include-path /usr/include/cuda -ccbin g++ -I../../common/inc -m64 -Xcompiler -fopenmp -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_60,code=compute_60 -o UnifiedMemoryStreams.o -c UnifiedMemoryStreams.cu
/usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h(444): error: identifier “nullptr” is undefined
/usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h(444): error: expected a “;”
/usr/include/c++/7/x86_64-redhat-linux/bits/c++config.h(2196): error: expected a “;”
Then you need to pass it to the compiler, read the
nvccman page. Examples:https://github.com/negativo17/ccminer/blob/master/ccminer.spec#L73
https://github.com/negativo17/ccminer/blob/master/ccminer.spec#L79-L80
I am trying to compile the julia package knet. Your examples got me past the c++ errors; however, I am not getting link errors eventhough I am using the -fPIC switch (see below). Do you have any suggestions on how to resolve this?
.
.
.
nvcc -ccbin /usr/bin/g++53 -Xcompiler -fPIC -c -O3 –use_fast_math -Wno-deprecated-gpu-targets –compiler-options “-shared -O3 -Wall -fPIC -fopenmp” -I/usr/include/cuda cuda22.cu -o cuda22.o
nvcc -ccbin /usr/bin/g++53 -Xcompiler -fPIC -c -O3 –use_fast_math -Wno-deprecated-gpu-targets –compiler-options “-shared -O3 -Wall -fPIC -fopenmp” -I/usr/include/cuda conv.cpp -o conv.o
nvcc -ccbin /usr/bin/g++53 -Xcompiler -fPIC –shared -O3 –use_fast_math -Wno-deprecated-gpu-targets –compiler-options “-shared -O3 -Wall -fPIC -fopenmp” -I/usr/include/cuda cuda1.o cuda01.o cuda11.o cuda12.o cuda13.o cuda16.o cuda17.o cuda20.o cuda21.o cuda22.o conv.o -o libknet8.so
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(parallel.o): relocation R_X86_64_32 against hidden symbol
gomp_global_icv' can not be used when making a shared objectgomp_tls_data’ can not be used when making a shared object/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(team.o): relocation R_X86_64_TPOFF32 against hidden symbol
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(proc.o): relocation R_X86_64_32 against hidden symbol
gomp_global_icv' can not be used when making a shared object.rodata.str1.8′ can not be used when making a shared object; recompile with -fPIC/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(affinity.o): relocation R_X86_64_32 against
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(alloc.o): relocation R_X86_64_32 against
.rodata.str1.8' can not be used when making a shared object; recompile with -fPICgomp_global_icv’ can not be used when making a shared object/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(env.o): relocation R_X86_64_32 against hidden symbol
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(error.o): relocation R_X86_64_32 against
.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC.rodata’ can not be used when making a shared object; recompile with -fPIC/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(task.o): relocation R_X86_64_32S against
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(target.o): relocation R_X86_64_32 against
.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC.rodata.str1.1′ can not be used when making a shared object; recompile with -fPIC/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(splay-tree.o): relocation R_X86_64_32 against
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(oacc-init.o): relocation R_X86_64_32 against
.rodata' can not be used when making a shared object; recompile with -fPIC.rodata.str1.1′ can not be used when making a shared object; recompile with -fPIC/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(oacc-host.o): relocation R_X86_64_32 against
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [Makefile:18: libknet8.so] Error 1
After upgrading to fedora 26 (yes, apparently I did this too soon), I get the login screen(gnome), but when I try to log in it:
1. under wayland, simply freezes
2. under X, kicks me back to the login screen.
In journalctl -k -b -1 I see a lot of refs to nouveau and none to nvidia, which I was not expecting, along with some bits that look like errors, such as:
kernel: nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid
kernel: nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22
I can provide more of this output if requested, but it seemed like a lot to dump in a comment. Note that this system worked just fine using nvidia drivers before upgrade, and had nouveau blacklisted both in grub opts and modprobe.d/blackllist. Any thoughts on how I can correct this issue, or further detail that may be needed to debug? Thanks!
Hey,
For me Fresh Fedora 26 install works OK with Negativo17 nvidia drivers in Xorg. Wayland freezes as you described.
I’m not a very advanced linux user, but with my limited knowledge I would do following:
1) Enter console.
2) sudo dnf -y remove *nvidia*
3) Reboot
4) Now you should be able to login to Gnome xorg/wayland
5) Reinstall the driver: sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686
Sorry for the delayed response. Faults, thanks, that did indeed work. I had started down this path, but dnf wanted to take a bunch of packages with it (like libreoffice). I was able to narrow down the list by setting most of them to userinstalled, so the reinstall list was more manageable. Note that with the newer cards (I have a 1050ti), you can’t even log in to your DE without the nvidia driver, nouveau seems to have no support yet (last I tried anyway). Not a big deal, you just ssh in or set init 3 and do the reinstall from there, just a note for others.
Possible bug with Fedora 26 Beta + Nvidia driver.
I have just installed two (Lenovo + Dell) Fresh 26 Beta installs on Optimus laptop. I haven’t managed to get work neither.
1) Fresh Fedora 26 Beta install
2) dnf update
3) Adding RPMFusion repos
4) Adding Nvidia + Multimedia Negativo17 repo
5) dnf update
6) Installing Nvidia driver: sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686
7) After reboot Nvidia driver is not loaded. Nouveau works with Xorg, Wayland not start.
Sorry for limited information for troubleshooting… I will dig deeper tomorrow.
Same here for my desktop. The nvidia driver is not working, just nouveau
Nevermind… It must been something what I did wrong. Today after reinstall all stuff works as intended. 🙂
I still can’t get wayland to start correctly with fully updated F26. Can you help me with this problem? Thanks.
nvidia-driver-libs-381.22-6.fc26.x86_64
dkms-nvidia-381.22-2.fc26.x86_64
nvidia-driver-cuda-libs-381.22-6.fc26.x86_64
nvidia-driver-381.22-6.fc26.x86_64
I didn’t change any settings except /usr/lib/modprobe.d/nvidia.conf
If I don’t change it, gnome falls back to X11
gnome-shell[1261]: Can’t initialize KMS backend: could not find drm kms device
gnome-session[1254]: gnome-session-binary[1254]: WARNING: App ‘org.gnome.Shell.desktop’ exited with code 1
If I changed it to “nvidia-drm.modeset=1” , gnome wayland starts but is very slow
gnome-shell[1634]: Failed to apply DRM plane transform 0: Invalid argument
org.gnome.Shell.desktop[1634]: Disabling glamor and dri3, EGL setup failed
org.gnome.Shell.desktop[1634]: Failed to initialize glamor, falling back to sw
Mutter is not compiled with EGLdevice in Fedora 26: http://pkgs.fedoraproject.org/cgit/rpms/mutter.git/tree/mutter.spec#n117
Follow up: I’ve unpacked the initramfs, and the nouveau.ko driver is present…
It doesn’t matter, the driver is excluded from loading in the initird:
https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L7
https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L15
https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L27
Do you come from a different installation, maybe wiht Nvidia’s own makeself or other packages? With the driver installed, try to rebuild the initird (
dracut -f force) and reboot.Also, make sure you don’t have any X configuration created by you.
dracut -f && reboot results in a white screen just before I’d normally get a GUI login screen. Xorg.0.log indicates the nvidia driver found no devices it recognised, but lspci lists the GeForce device. There are no loose X configuration bits. It looks like the Intel HD graphics are on and the GeForce is off.
Can you paste the output of the following commands?
lsmod | egrep "intel|nouveau|nvidia"rpm -qa *nvidia* kernel* | sort
lspci | grep -i vga
Hi there! Thank you for all the work!
I have a desktop running Centos 7 with an i7-3770 that has an integrated GPU and an nVidia GTX980. At the moment I am not using the intel GPU at all (the monitor is attached to the nvidia GPU). However since this machine is for CUDA development, I would like to use the Intel GPU for displaying the desktop and the nVidia GPU only for compute. I am a little puzzled on how to do that, according to your instructions.
My /etc/default/grub file looks like this:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=”$(sed ‘s, release .*$,,g’ /etc/system-release)”
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT=”console”
GRUB_CMDLINE_LINUX=”nouveau.modeset=0 rd.driver.blacklist=nouveau crashkernel=auto rd.lvm.lv=idefix/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=idefix/root vconsole.keymap=us rhgb rd.driver.blacklist=nouveau”
GRUB_DISABLE_RECOVERY=”true”
GRUB_GFXPAYLOAD_LINUX=text
How should I edit this in order to achieve what you are suggesting?
Thank you in advance,
Andreas
If you have an Nvidia and an Intel card, and the Intel is for display, you have to do some fiddling around.
I will update the instructions. On Fedora, is much easier, on CentOS there’s some change required.
Sorry to bug you, but I couldn’t find help anywhere else. Gnome won’t start in wayland mode, falls back to x11.
rpm -qa | grep nvidia
nvidia-driver-libs-381.22-6.fc26.x86_64
dkms-nvidia-381.22-2.fc26.x86_64
nvidia-driver-cuda-libs-381.22-6.fc26.x86_64
nvidia-driver-381.22-6.fc26.x86_64
gnome-shell[1384]: Can’t initialize KMS backend: could not find drm kms device
gnome-session[1363]: gnome-session-binary[1363]: WARNING: App ‘org.gnome.Shell.desktop’ exited with code 1
gnome-session-binary[1363]: WARNING: App ‘org.gnome.Shell.desktop’ exited with code 1
gnome-session-binary[1363]: Unrecoverable failure in required component org.gnome.Shell.desktop
gdm-launch-environment][1185]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Mutter is not compiled with EGLdevice in Fedora 26: http://pkgs.fedoraproject.org/cgit/rpms/mutter.git/tree/mutter.spec#n117
Excellent work and thanks for accompanying it with such a complete technical writeup of how it works!
I am curious about the Nouveau fallback. You say that if the nvidia kernel module fails to load, the system automatically falls back to nouveau?
But I presume that the nouveau kernel module was blacklisted somewhere along the way, which is what makes the nvidia proprietary module get loaded instead. So how does the nouveau kernel driver get loaded in the fallback path?
Pretty simple, most of the explanation is in the spec file (https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L4-L32). On Fedora 25 there is only
rd.driver.blacklist=nouveaudefined, so that means that apart fromnouveaubeing included & loaded from theinitrd, there is nothing preventing it from loading, modesetting the screen, etc. The blacklist configuration (https://github.com/negativo17/nvidia-driver/blob/master/nvidia.conf#L1) is also used only when callingmodprobe -bfromudev, so it’s ignored by the systemd unit file which explicitly loads the module (https://github.com/negativo17/nvidia-driver/blob/master/nvidia-fallback.service#L10)Has anyone been able to get virtio-gpu/virGL to work in fedora 25 or 26 ? When I try and load a guest with virtio/spice with open GL enabled the VM crashes a few moments after it launches with:
qemu-system-x86_64: Couldn’t find current GLX or EGL context.
Sorry that is using the proprietary nvidia drivers 381.22 / kernel 4.1.1.3-300
there is no way to go back to 378 anymore? I only get 381 versions on dnf. I’m getting dramati kwin lag in fedora 25…
Ok, I did hit it a little more.
glxinfo showed Gallium, weirdly, with a backed xorg, nvidia-settings discord. So I guessed my system is loading nouveau even with 381.22-6. I did a dirty trick moving nouveau DRM driver from /usr/lib/modules and doing ”dracut -f” and everything is fine again.
No need to remove the module, just rebuild the initrd:
Probably you had it included in the initrd from some previous installation.
I’m somewhat out of time but when I can I will return with the results, Thanks.
It worked, but now I did a upgrade to Fedora 26 and for some reason it didn’t build nvidia modules, nvidia-driver and dkms-nvidia are installed but dkms status gives nothing and the modprobe didn’t show any nvidia driver. I reverted to my last snapshot, any Idea why?
There’s been talk about Gnome 3.24 and Mesa 17.1 including support for running Wayland on Nvidia proprietary drivers. Is it possible to run Wayland in F26 with the latest drivers?
Hey, I have asked this before, but I ask now again about PrimeSync. I have now extremely good change to try out PrimeSync on two different Optimus laptop. One is Lenovo W540 Intel/Quadro and another is brand new Dell Intel/Geforce Pascal. Both has clean Fedora 25 and Negativo17 nvidia Repo added.
What should I do for FRESH Fedora 25 to enable PrimeSync. I can do all sort of testing these as those are not production laptops for while.
(I don’t want to break my own laptop again with testing Primesync) 🙂
Thank you.
If you want to test on your system, just do the following as root:
If for whatever reason you have support for PRIME Synchronization but wish to disable it, you may disable it via
xrandr –outputand re-enable it viaxrandr –output.Uh, and please provide feedback 🙂
echo gives me a permission denied even with sudo, but I created a file with nano where I added option nvidia-drm modeset=1. I ran depmod -a and reboot.
Nothing happens. 🙂
Setup: Intel® HD Graphics 630 + Pascal 1050 Ti Optimus
Then it’s working 🙂
Sadly tearing is still in there…. 🙁 How can I check if PrimeSync is in use?
There’s some debugging you can read here:
https://devtalk.nvidia.com/default/topic/957814/prime-and-prime-synchronization/?offset=136
Hey,
Tried now with Fedora 26 on W540. Intell 4000 / Quadro K2100M setup.
Same as with Dell… nothing happens. Screen Tearing is still there.
I ran xrandr –verbose which shows that my display is PRIME Sync 0.
PRIME Synchronization: 0
supported: 0, 1
When I try to enable it then screen just flashes and its back to 0.
Nvidia-bug-report log: https://drive.google.com/open?id=0B9Gh7bg64e8KVWdxMW9GRHl3ZFU
[fierce.brake@movil-01 ~]$ sudo rpm -qa nvidia*
nvidia-modprobe-381.22-1.fc25.x86_64
nvidia-driver-381.22-5.fc25.x86_64
nvidia-libXNVCtrl-381.22-1.fc25.x86_64
nvidia-xconfig-381.22-1.fc25.x86_64
nvidia-settings-381.22-1.fc25.x86_64
nvidia-driver-libs-381.22-5.fc25.x86_64
nvidia-driver-libs-381.22-5.fc25.i686
[fierce.brake@movil-01 ~]$
I did “dracut -f && reboot” but no luck after reboot.
What else should i try ?
hello! i own an asus k556u laptop with nvidia geforece 940mx card.
WHn i run nvidia-settings i get this:
ERROR: Unable to find display on any available system
and when i launch games they look awful, as if the driver is not working.
fierce.brake@movil-01 nvidia]$ lsmod | grep -E -i “nvidia|nouveau”
nvidia_drm 45056 0
nvidia_modeset 811008 1 nvidia_drm
nvidia 11546624 1 nvidia_modeset
drm_kms_helper 155648 2 i915,nvidia_drm
drm 352256 13 i915,nvidia_drm,drm_kms_helper
[fierce.brake@movil-01 nvidia]$ dkms status
nvidia, 381.22, 4.10.14-200.fc25.x86_64, x86_64: installed
It seems it’s loading nouveau before nvidia.
Can you confirm that you have
nvidia-driver-381.22-5.fc25.x86_64installed?Without doing anything special, with the system in the current state, can you do a:
dracut -f && rebootAnd let me know? I think somehow your
nouveaumodule is in theinitrd.[fierce.brake@movil-01 ~]$ sudo rpm -qa nvidia*
nvidia-modprobe-381.22-1.fc25.x86_64
nvidia-driver-381.22-5.fc25.x86_64
nvidia-libXNVCtrl-381.22-1.fc25.x86_64
nvidia-xconfig-381.22-1.fc25.x86_64
nvidia-settings-381.22-1.fc25.x86_64
nvidia-driver-libs-381.22-5.fc25.x86_64
nvidia-driver-libs-381.22-5.fc25.i686
[fierce.brake@movil-01 ~]$
I did “dracut -f && reboot” but no luck after reboot.
What else should i try ?
Hi, just a quick question. I know that nvidia provides kms support since last few versions and that should enable plymouth native support. However, enabling modesetting and adding nvidia modules to initrd doesnt seem to work. There is noticable blink just when kernel is loaded, indicating it tries to enter graphical mode, but second later it falls back to text mode boot, and continues.
Was anyone successfull on using nvidia-drm modesetting and plymouth in Fedora 25?
Actually the KMS support for the Nvidia driver is only for Wayland. There is no console support, the console would still be in text mode. So plymouth will be no different and would run at VGA resolutions. Unless of course you are on an Optimus laptop, in which case plymouth is running on the KMS console provided by the Intel driver.
file:///usr/share/doc/nvidia-driver/html/kms.html
The
nvidia-drmmodule must not be in theintird, or you will have all sort of issues when upgrading the drivers.Anyway, if you want to test on your system, just do the following as root:
This should allow you to select Wayland from the login screen and see the desktop if you are running on the Nvidia drivers. Please note that this is not stable for everyone at the moment.
I had this line in modprobe.d already, however it changed nothing since im not using gnome. Only thing i was interested to check if its possible to have nice fancy boot splash at startup. Well its something i can live without 🙂 cheers, SLAANESH and thanks for informations.
Well, if you just installed your system using UEFI, your console runs on
efifbwhich has KMS console support, thus giving you the Plymouth graphical boot without doing anything.I have EFI system, however fedora is installed in old fashion BIOS method, thus there is no framebuffer device at startup. From what i’ve read there is an issue with plymouth actually not asking the driver for desired video mode, and that causes to fall back to text boot. You can find this info and plymouth patch on nvidia forums.
One another thing: i noticed multimedia repo still has nvidia-378 driver and nvidia repo has 381 already.
Well, my experience is:
efifbis used at boot. As soon as a proper drivers is loaded (intelfb,nouveaufb,mgafb, etc.) the framebuffer is stolen and attached to the new driver. Plymouth runs on that one.Example on my system:
[ 0.921216] fb0: EFI VGA frame buffer device[ 21.783776] fb: switching to inteldrmfb from EFI VGA
[ 21.916407] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 22.158371] nouveau 0000:01:00.0: fb: 6144 MiB GDDR5
[ 22.589653] nouveau 0000:01:00.0: DRM: allocated 1024x768 fb: 0x60000, bo ffff8c2dfecb8000
[ 22.590078] fbcon: nouveaufb (fb1) is primary device
[ 22.590079] fbcon: Remapping primary device, fb1, to tty 1-63
[ 22.719951] nouveau 0000:01:00.0: fb1: nouveaufb frame buffer device
[ 26.885991] fbcon: Remapping primary device, fb0, to tty 1-63
If you are using the Nvidia drivers, there is no framebuffer console, so you have the X drivers loaded (or KMS with Wayland), but if you switch back, you are switching the console back to
efifb.I know, I’m preparing more updates there to make just one push to the repositories.
Thanks from fast reply! Sadly after 381.22-4 patch it still falls back to nouveau…
I patched + booted = No luck
I removed Nvidia driver + booted + Reinstalled + Reboot = No luck
I patched 381.22-4 + rebooted on Fedora 26 Alpha on identical hardware = Works
Please do the following, if you still have the problem. With the drivers installed (doesn’t matter if on Nouveau or Nvidia) run:
dracut -fAnd reboot. Please let me know.
Isn’t working. :/
As soon as it is booted, check that the Nvidia modules are built and loaded. If those are, the rest should follow.
lsmod | grep -E -i "nvidia|nouveau"If they are not, and you are usign DKMS, check that they are built:
dkms statusIf not, add/build/install them:
dkms add nvidia/381.22dkms build nvidia/381.22
dkms install nvidia/381.22
If using akmods, make sure that the rpm package for the modules is installed:
rpm -qa kmod-nvidia\*If not, build it with:
akmods --forcenouveau 1601536 2
mxm_wmi 16384 1 nouveau
ttm 98304 1 nouveau
i2c_algo_bit 16384 2 nouveau,i915
drm_kms_helper 155648 2 nouveau,i915
drm 352256 11 nouveau,i915,ttm,drm_kms_helper
wmi 16384 2 mxm_wmi,nouveau
video 40960 3 thinkpad_acpi,nouveau,i915
Looks like this.. I also run dkms commands and rebooted.
No luck 🙁
I updated 381.22-5, but no luck. Might be that I have something weird going in my system.
I did dracut -f
No secure boot ? (forgot to sign the mod if you usually do it)
No dmesg related to nvidia ?
“ll /lib/modules/
uname -r/extra” give you the nvidia module ? (so compilation is correct)I just re-installed Korora 25 and drivers works just great. Must been something wrong in my setup.
I have Korora 25 Gurgle kernel x86_64 Linux 4.10.14-200.fc25.x86_64 with xfce4 xfwm4 GPU Gallium 0.4 in NV117.
I got nvidia-driver 381.22 this morning.
Since this update fan of graphic card is screaming and makes a lot of noise. Speed of fan is constantly changing up and down.
When calling Nvidia X Server setting it says: You do not appear to be using nvidia x driver. Please edit yr config file (run nvidia-xconfig as root). I did it. After that no more xfce4 anymore.
Then i removed nvidia-driver install completely “dnf remove *nvidia*” and did fresh install “dnf install nvidia-driver nvidia-settings kernel-devel”.
This brings back xfce4 with driver 381.22.
But fan is still same very noisy and loud. Going up and down.
When calling Nvidia X Server setting it still says: You do not appear to be using nvidia x driver. Please edit yr config file (run nvidia-xconfig as root) again.
How to downgrade to driver version before?
I have no Fan issue, but I’m quite sure that is caused because Nouveau drivers are in use instead of Nvidia ones.
BUT I do have same issue with 381.22 as you do… those not get loaded after upgrade. I did “dnf history undo id” to fix this for now.
I hope some advices how to make it work.
ARGH! dnf history undo didn’t saved me from trouble! I’m stuck with Nouveau drivers for now… 🙁
I found the issue, it is related to the introduction of the planned fallback service. The systems loads
nouveauand the Mesa stack if there is any problem with the Nvidia drivers.I was able to reproduce the problem on one laptop, new build coming in a minute.
Just a
dnf updateand a reboot should be fine.I found the issue, it is related to the introduction of the planned fallback service. The systems loads
nouveauand the Mesa stack if there is any problem with the Nvidia drivers.I was able to reproduce the problem on one laptop, new build coming in a minute.
Just a
dnf updateand a reboot should be fine.Hey,
Thank you very much from fast response.
-This issue got fixed in Fedora 26 Alpha (Lenovo W540 Quadro K2100M)
-This issue is STILL in Fedora 25 (Lenovo W540 Quadro K2100M) –> I even removed all Nvidia related from this workstation and I did reinstall, but no success. ( 1) sudo dnf -y remove *nvidia* –> 2) sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686 )
Sorry for that, there’s another small fix coming:
https://github.com/negativo17/nvidia-driver/commit/f1f99b401b98a159e972acc6c179b5a100570d88
There’s a race condition if checking only the device. This became apparent just with a more widespread use, as on my systems it did not happen except on one this morning.
I found the issue, it is related to the introduction of the planned fallback service. The systems loads
nouveauand the Mesa stack if there is any problem with the Nvidia drivers.I was able to reproduce the problem on one laptop, new build coming in a minute.
Just a
dnf updateand a reboot should be fine.There are the last 3 revisions of each package available in the repository.
Hi, is there a way to install cuda-cudnn 5? Tensorflow is not compatible with cuda-cudnn 6 at the moment
There is
cuda-cudnn5.1as a compatibility package:dnf list cuda-cudnn\*Do the drivers here work with Bumblebee? the kmod-nvidia driver and bumblebee have been the only way I can get my laptop to boot (dual Intel and nVidia GPUs) and get into gdm. I currently have an issue where I need to enable to nvidia libraries for CUDA to work, but it breaks Xorg/gdm (white screen before login).
If I can use these drivers for CUDA and not bother with bumblebee and still be able to get into gdm, that would be even better.
Hi slaanesh,
Thanks for the work on the repo.
I’m having some issues on F26, which is actually why I found your repo
Reboot after an update to kernel 4.10.10, my drivers stoped working. Long story short, I installed the packages from here and it is still not working.
No errors in messages nor Xorg.log files, the last messages are Option “fd” “46” and systemd-logind: got pause for XX:XX
any ideas on how to debug this futher?
B
Thanks for all of your efforts in creating these repositories.
I just installed the drivers and cuda packages under Fedora 25.
I just got a new Nvida 1070 card and the graphics work beautifully.
However, the cuda applications are not recognizing the card.
Could I be missing a configuration setting somewhere or a conflict from
a file for my previous Nvidia GTX280 card?
What do you mean by “not recognized”? Did you install the
nvidia-driver-cudapackage and reboot (it requires thenvidia-uvmmodule to be loaded).The problem was between the seat and keyboard. I had all of the cuda packages installed except nvidia-driver-cuda. it works now. Thanks.
Thank you for the repo. I have GTX 980M and the driver works with fedora 25. On same laptop I installed centos 7.3 workstation on second disk (uefi, secure boot disabled) and the driver loaded but no logon screen. I tried with kmod then dkms and same result. The driver loaded but just bomb out with no logon screen. Thanks in advance for any help.
Hi, how do I load nvidia-uvm?
You install
nvidia-driver-cudaand reboot. Then check this for an explanation:$ cat /usr/lib/modprobe.d/nvidia-uvm.confThanks for the package! However, the akmod compile fails on me on a fresh new F26-alpha (kernel 4.11.0-0.rc5):
X86_64/nvidia-drm/nvidia-drm-drv.c:682:31: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.unload = nvidia_drm_unload,
Do you know if any fix is incoming, or should I go back to F25?
Normally Nvidia does not support unreleased kernels.
There’s a patch if you want that basically changes the license though (towards the end there’s the patch):
https://github.com/negativo17/nvidia-driver/issues/19
Running Fedora 25 Gnome. Do you save the nvidia settings as “nvidia.conf” or “nvidia-xorg.conf” in the /etc/x11 folder? Which one works? When I reboot the boxes are unchecked (ForceCompositionPipeline and Force Full Composition Pipeline).Thanks.
It depends on what you need to do. If you just want to add an additional settings to the Device section then you might just edit
/etc/X11/xorg.conf.d/10-nvidia.conf.Hi negativo,
For some reasons, dkms seems unable to build with following result
DKMS make.log for nvidia-378.13 for kernel 4.10.5-200.fc25.x86_64 (x86_64)
Sun Mar 26 23:30:10 PDT 2017
Makefile:19: /Kbuild: No such file or directory
make: *** No rule to make target ‘/Kbuild’. Stop.
kernel-devel is already installed as listed below
$ dnf list installed *kernel* | grep 4.10.5-200
kernel.x86_64 4.10.5-200.fc25 @updates-testing
kernel-core.x86_64 4.10.5-200.fc25 @updates-testing
kernel-devel.x86_64 4.10.5-200.fc25 @updates-testing
kernel-headers.x86_64 4.10.5-200.fc25 @updates-testing
kernel-modules.x86_64 4.10.5-200.fc25 @updates-testing
kernel-tools.x86_64 4.10.5-200.fc25 @updates-testing
kernel-tools-libs.x86_64 4.10.5-200.fc25 @updates-testing
Graphic card is Nvidia Geforce GTX 460v2
Works fine here, you should check specific DKMS logs for the module in
/var/lib/dkmsI have Optimus Asus Geforce 930M enabled system on Fedora 25. I install your driver and Nvidia GPU is working fine along with “nvidia-smi” from CUDA packages, other options never worked correctly. Now my X11 is on Nvidia GPU, I can see glxgears and everything performing excellent.
Now when I use my laptop on Battery power, how do I switch to Intel Integrated Graphics on your drivers, switcheroo?
Any pointers would be appreciated. Thanks in Advance.
BTW, Great Work! on Fedora 25, nothing else works. Yours is just perfect.
Unfortunately not, that’s limited by Nvidia design. With the Nvidia solution, both chipsets are always on unfortunately. The switcheroo part disappears the moment the nvidia kernel module is loaded. With Optimus enabled, the rendering is always done by the Nvidia chipset, so you can not switch off the discrete card if you don’t use it.
Let me explain, I was on Ubuntu Optimus configuration the other day, you can prime-select to Intel, log out and log back in, and Intel drives the display, the Nvidia module is unloaded. I was looking for a similar solution in Fedora.
For example, when I want to run CUDA apps, I will switch to Nvidia and system will load Nvidia Modules, when I just want lightweight usage, Intel GPU is fine. Eventhough Nvidia GPU is “powered on”, it will not perform any computation…
I don’t want to turn either of them off…
There is none like that. That is unsupported by both Nvidia and upstream X.org components, it does switch GL libraries on the fly etc. The correct implementation requires GLVND support (so GL libraries on demand) and plain RandR support with Sink offloading. The Ubuntu implementation uses an acpi module derived from Bumblebee that triggers a specific ACPI call per hardware module.
In my latest job that very thing would actually break some systems up to the point that they required a hard reboot to revive the Nvidia card. Even going in the bios settings would not allow you to bring the card back to life.
Thanks for the excellent info. Yes ubuntu has Nvidia Prime fork which allows to do so. I found this project to claim the same functionality, I haven’t tried it. I will give it a shot & will update.
https://github.com/bosim/FedoraPrime
Agreed, the enterprise systems shouldn’t toggle this thing on the fly. This is something which concerns more to personal user.
Hey Subodh, I recently got a laptop with similar configs – asus geforce 940mx, installed fedora 25. I installed negativo’s drivers but X11 seems to be picking up intel, not nvidia gpu. Could you please tell me your xorg.conf file contents? Where could I be going wrong? I’d like to use gpu to render display as well as take tensorflow compute load. I
Recent F26 (branched) mesa-libGL update is conflicting with /usr/lib64/libGLX_indirect.so.0 from nvidia-driver-libs – you’re probably already aware. Is this going to require a package update?
Nevermind – I see the post below. I’m guessing the update hasn’t been pushed for devel repos yet. 🙂