Nvidia kernel error linux

Arch Linux

You are not logged in.

#1 2010-06-22 13:34:49

Unable to load the kernel module ‘nvidia.ko’ [SOLVED]

After my most recent kernel upgrade, I can’t get my GUI to run. I’ve tried reinstalling the nvidia driver to no avail.
Any insight would be greatly appreciated. I’m using a GeForce 8400 GS

Last edited by wsims (2010-06-22 15:06:04)

#2 2010-06-22 14:02:19

Re: Unable to load the kernel module ‘nvidia.ko’ [SOLVED]

Install whatever driver you need for your card (nvidia, nvidia-173xx, nvidia-96xx) from the repo. novueau is in the kernel now, if it gets loaded by default blacklist it in rc.conf and specify nvidia in xorg.conf.

Last edited by hokasch (2010-06-22 14:03:05)

#3 2010-06-22 14:05:15

Re: Unable to load the kernel module ‘nvidia.ko’ [SOLVED]

i had quite the same problem, just blacklist the nouveau module in the rc.conf and reboot! :>

#4 2010-06-22 14:06:54

Re: Unable to load the kernel module ‘nvidia.ko’ [SOLVED]

Are you using the stock kernel? Did you reboot to the updated kernel? Did you use the installer directly from nvidia.com?

Evil #archlinux@freenode channel op and general support dude.
. files on github, Screenshots, Random pics and the rest

#5 2010-06-22 14:08:36

Re: Unable to load the kernel module ‘nvidia.ko’ [SOLVED]

if you used the packages from repos, the blacklist is done automatically in nvidia,

but i guess you just want to mess your system by using unsupported and very bad ways and you are way smarter than the devs if you used that installer

Last edited by wonder (2010-06-22 14:10:01)

Give what you have. To someone, it may be better than you dare to think.

#6 2010-06-22 14:15:57

Re: Unable to load the kernel module ‘nvidia.ko’ [SOLVED]

I’ve been using the drivers straight from the nvidia website. I’ve uninstalled «nvidia’s» driver, rebooted, and installed the driver from the repos. It didn’t work, but i’ll tinker with it a bit more. I’ll report back shortly. Thanks guys.

#7 2010-06-22 14:37:15

Re: Unable to load the kernel module ‘nvidia.ko’ [SOLVED]

I’ve been using the drivers straight from the nvidia website. I’ve uninstalled «nvidia’s» driver, rebooted, and installed the driver from the repos. It didn’t work, but i’ll tinker with it a bit more. I’ll report back shortly. Thanks guys.

you actually need to reboot again after installing nvidia package because nouveau is already loaded when the actually installation occurs

Give what you have. To someone, it may be better than you dare to think.

Источник

Arch Linux

You are not logged in.

#1 2017-04-11 23:37:28

[SOLVED] ERROR: Unable to build the NVIDIA kernel module.

I have done lots of installing and uninstalling of the nvidia package and nvidia-utils package trying to get the official drivers to work. I eventually decided to intall it via the NVIDIA website. However, I keep getting:

Content of /var/log/nvidia-installer.log:

Last edited by GNUGradyn (2017-04-12 16:24:26)

#2 2017-04-11 23:47:34

Re: [SOLVED] ERROR: Unable to build the NVIDIA kernel module.

Welcome to the arch linux forums GNUGradyn.
You appear to be ignoring this warning from NVIDIA

Warning: Avoid installing the NVIDIA driver through the package provided from the NVIDIA website. Installation through pacman allows upgrading the driver together with the rest of the system.

#3 2017-04-12 03:02:50

Re: [SOLVED] ERROR: Unable to build the NVIDIA kernel module.

Thank you. I ran sudo pacman -S nvidia, and it deffinantly did not work.
Only 1 monitor works
NVIDIA control panel is not installed
I can’t do anything directly related to the video card (like GPU cyclone rendering)

#4 2017-04-12 03:38:20

Re: [SOLVED] ERROR: Unable to build the NVIDIA kernel module.

EDIT: Figured it out, I have to use a legacy driver (nvidia-340xx) with my card. Not sure how to close this thread, but everything is working as expected now

#5 2017-04-12 05:42:53

Re: [SOLVED] ERROR: Unable to build the NVIDIA kernel module.

Hi there GNUGradyn

If you want to close the thread use the report button and ask the moderators to do so. But you don’t have to do that. The normal thing to do when you’ve got your issue resolved is to edit your opening post and add [SOLVED] to the beginning of the title.

Источник

ERROR: Unable to load the kernel module ‘nvidia.ko’

OpenSUSE Tumbleweed, kernel 4.10.1-1. После обновки ядра переустанавливаю драйвер nvidia. Драйвер компилируется нормально, nouveau забанен, как и rivafb и nvidiafb. После компиляции драйвера появляется следующее сообщение

Не смотрел, что там за сообщение появляется, просто факт — блоб невидии на 4.10 у меня не работает, экран в сосноли начинает моргать как припадочный, даже залогиниться не удаётся.

Откатился, сижу на 4.9.11, жду когда неаидия выкатит новый драйвер или тролльвардс — новое ведро. Интересно, это как-то связано с этим? http://www.opennet.ru/opennews/art.shtml?num=46107

http://pastebin.com/u2STDSNd
Не благодари. Но ТСу этот патч не поможет.

PS: А хотя хз, может, и поможет.

А у меня работает.

Работает он только после патча. Без патча даже не компилируется.

Это я уже без понятия, этим мантейнеры дистрибутива занимаются.

уже патчил им я ж говорю: все компилируется, но почему-то не может загрузить модуль

У меня работает именно с этим патчем и драйвером 378.13.

Secure Boot случайно не включен?

нет, обычная загрузка

Решение

На форуме nvidia получил решение

Make sure nomodeset is in your /etc/default/grub at the end of the GRUB_CMDLINE_LINUX_DEFAULT options

grub2-mkconfig -o /boot/grub2/grub.cfg

to update your grub, and reboot.

Also need to add nv_unregister_procfs in kernel/nv.c

right after line 1041:

This worked succesful for me using (last updated) OpenSuSE Tumbleweed 20170303 kernel 4.10.1-1-default x86_64

Источник

How to unload kernel module ‘nvidia-drm’?

I’m trying to install the most up-to-date NVIDIA driver in Debian Stretch. I’ve downloaded NVIDIA-Linux-x86_64-390.48.run from here, but when I try to do

as suggested, an error message appears.

When I try to find out who is using nvidia-drm (or nvidia_drm ), I see nothing.

And when I try to remove it, it says it’s being used.

I have rebooted and started in text-only mode (by pressing Ctrl+Alt+F2 before giving username/password), but I got the same error.

Besides it, how do I «know that my kernel supports module unloading»?

I’m getting a few warnings on boot up related to nvidia, no idea if they’re related, though:

12 Answers 12

I imagine you want to stop the display manager which is what I’d suspect would be using the Nvidia drivers.

After change to a text console (pressing Ctrl + Alt + F2 ) and logging in as root, use the following command to disable the graphical target, which is what keeps the display manager running:

At this point, I’d expect you’d be able to unload the Nvidia drivers using modprobe -r (or rmmod directly):

Once you’ve managed to replace/upgrade it and you’re ready to start the graphical environment again, you can use this command:

CUDA Installation

1) Download the latest CUDA Toolkit

2) Switch to tty3 by pressing Ctl+Alt+F3

3) Unload nvidia-drm before proceeding.

3a) Isolate multi-user.target

3b) Note that nvidia-drm is currently in use.

3c) Unload nvidia-drm

4d) Note that nvidia-drm is not in use anymore.

5) Go to your download folder and run the cuda installation.

6) Answer any prompts during installation.

7) When installation has finished, confirm that the CUDA Version has been updated.

8) Start the GUI again.

lsof lists any files that are in use by userspace processes. But nvidia_drm is a kernel module, so lsof won’t necessarily see whether or not it is actually in use. (The module file won’t be open because the kernel has already completely loaded it into RAM. But the module might be providing services to the userspace or other kernel components, and that is what prevents the unloading of the module.)

Run lsmod | grep nvidia.drm and see the numbers to the right of the nvidia_drm module name. The first number is simply the size of the module; the second is the use count. In order to successfully remove the module, the use count must be 0 first.

If the X11 server is running and using the nvidia driver, then the nvidia_drm kernel module will most assuredly be in use. So you’ll need, at the very least, switch into text console and shutdown the X11 server. Usually this can be done by stopping whichever X Display Manager service you’re using (depends on which desktop environment you’re using).

As the error message said, if you are running nvidia-persistenced , you’ll need to stop that too before you can unload the nvidia_drm module.

I had a similar problem.

*Reason: nvidia.drm package was in use

I fixed it by purging all NVIDIA packages.

Remove all previous NVIDIA installations with these 2 commands:

$ sudo apt-get purge nvidia*
$ sudo apt-get autoremove

Module should be removed.

Reboot and go forth.

I solved this problem by disabling the GUI, rebooting, logging in and installing the driver, enabling GUI, and reboot.

Please make sure you know your username and password.

Open a terminal and write

Now login and you’ll get to a terminal directly, install the driver Do note that I am installing here the 440.44 so you need to modify for your driver version.

After installing the driver enable the GUI and Reboot:

You should be done

In my case, nvidia-smi reported the new version 440.44, whine in the Ubuntu 18.04 Software & Updates Utilities, Additional Drivers Tab shows 435!! Another NVIDIA mystery, but heck my new docker works.

You report in comments that stopping the systemd-logind service takes you back to the graphic login. If you have a graphical login then X is running, so the video driver is loaded and in use. This very likely explains in part why the nvidia-drm module is in use.

Additionally, you betray an apparent misconception when you say

I have rebooted and started in text-only mode (by pressing Ctrl+Alt+F2 before giving username/password), but I got the same error.

Pressing Ctrl+Alt+F2 switches to a virtual terminal #2, which may well be configured for text-mode login, but that’s a far cry from «starting in text mode». If you had a graphical login screen on the default virtual terminal then X is running, and switching to a different VT doesn’t change that. You’re just logging in to a non-X session.

The first and easiest thing to try is to actually shut down the X server. The old-school way to do this would be to log in to your text-mode session and execute the command

to switch to runlevel 3. That should work with systemd, too, but the native systemd way would be to instead run

Both of those require privilege, of course, so you’ll need to use sudo or make yourself root.

If that doesn’t remove the module, or at least make it possible for you to do so manually, then your next best bet would be to boot the system directly into runlevel 3 (multi-user target), or maybe even into runlevel 1 (rescue target). I usually do this by adding «3» (or «1») to the end of the kernel argument list at boot time via the bootloader. You can also change the default boot target as described in this article.

Do also note that the nVidia driver is available in pre-built packages for most Linux distros. Few include those packages in their own standard repos because the driver is, after all, proprietary, but you can surely find a reputable 3rd-party repo that has it. I strongly recommend using such packages instead of running the installer directly, but to get there from where you are now, you may need to first manually uninstall the driver.

Источник

NVIDIA/Troubleshooting

Contents

Corrupted screen: «Six screens» Problem

For some users, using GeForce GT 100M’s, the screen gets corrupted after X starts, divided into 6 sections with a resolution limited to 640×480. The same problem has been recently reported with Quadro 2000 and hi-res displays.

To solve this problem, enable the Validation Mode NoTotalSizeCheck in section Device :

‘/dev/nvidia0’ input/output error

The factual accuracy of this article or section is disputed.

This error can occur for several different reasons, and the most common solution given for this error is to check for group/file permissions, which in almost every case is not the problem. The NVIDIA documentation does not talk in detail on what you should do to correct this problem but there are a few things that have worked for some people. The problem can be a IRQ conflict with another device or bad routing by either the kernel or your BIOS.

First thing to try is to remove other video devices such as video capture cards and see if the problem goes away. If there are too many video processors on the same system it can lead into the kernel being unable to start them because of memory allocation problems with the video controller. In particular on systems with low video memory this can occur even if there is only one video processor. In such case you should find out the amount of your system’s video memory (e.g. with lspci -v ) and pass allocation parameters to the kernel, e.g. for a 32-bit kernel:

If running a 64bit kernel, a driver defect can cause the NVIDIA module to fail initializing when IOMMU is on. Turning it off in the BIOS has been confirmed to work for some users. [1]User:Clickthem#nvidia module

Another thing to try is to change your BIOS IRQ routing from Operating system controlled to BIOS controlled or the other way around. The first one can be passed as a kernel parameter:

The noacpi kernel parameter has also been suggested as a solution but since it disables ACPI completely it should be used with caution. Some hardware are easily damaged by overheating.

Crashing in general

• Try disabling RenderAccel in xorg.conf.
• If Xorg outputs an error about «conflicting memory type» or «failed to allocate primary buffer: out of memory» , or crashes with a «Signal 11» while using nvidia-96xx drivers, add nopat to your kernel parameters.
• If the NVIDIA compiler complains about different versions of GCC between the current one and the one used for compiling the kernel, add in /etc/profile :

• If Xorg is crashing , try disabling PAT. Pass the argument nopat to kernel parameters.

More information about troubleshooting the driver can be found in the NVIDIA forums.

Bad performance after installing a new driver version

If FPS have dropped in comparison with older drivers, check if direct rendering is enabled ( glxinfo is included in mesa-demos ):

If the command prints:

A possible solution could be to regress to the previously installed driver version and rebooting afterwards.

Avoid screen tearing

Tearing can be avoided by forcing a full composition pipeline, regardless of the compositor you are using. To test whether this option will work, run:

Or click on the Advanced button that is available on the X Server Display Configuration menu option. Select either Force Composition Pipeline or Force Full Composition Pipeline and click on Apply.

In order to make the change permanent, it must be added to the «Screen» section of the Xorg configuration file. When making this change, TripleBuffering should be enabled and AllowIndirectGLXProtocol should be disabled in the driver configuration as well. See example configuration below:

If you do not have an Xorg configuration file, you can create one for your present hardware using nvidia-xconfig (see NVIDIA#Automatic configuration) and move it from /etc/X11/xorg.conf to the preferred location /etc/X11/xorg.conf.d/20-nvidia.conf .

Multi-monitor

For multi-monitor setup you will need to specify ForceCompositionPipeline=On for each display. For example:

Without doing this, the nvidia-settings command will disable your secondary display.

You can get the current screen names and offsets using —query :

The above line is for two 3840×2160 monitors connected to DP-2 and DP-4. You will need to read the correct CurrentMetaMode by exporting xorg.conf and append ForceCompositionPipeline to each of your displays. Setting ForceCompositionPipeline only affects the targeted display.

/.nvidia-settings-rc as 0/XVideoSyncToDisplayID= or by installing nvidia-settings and using the graphical configuration options.

Avoid screen tearing in KDE (KWin)

The problem is caused by incorrect assumption by the KDE devs about the behaviour of glXSwapBuffers and should be fixed in Plasma 5.12, Plasma 5.15, Plasma 5.16 [2]. Additionally, NVIDIA#DRM kernel mode setting may be required.

Legacy solutions

For posterity, these are the legacy workarounds. Do not apply both workarounds because this may lead to high CPU load [3].

1. GL threads

Set GL threads to sleep by exporting __GL_YIELD=»USLEEP» to just kwin_x11 . Unlike setting up a global environment variable, this affects only KWin. It should also have the advantage over other workarounds, like forcing triple buffering or forcing composition pipeline in the driver, that it does not introduce additional stuttering when scrolling in Firefox or moving windows.

The script can be executed automatically at login with an autostart script:

Flag the script as executable.

The sleep argument helps to prevent issues when KWin is restarted/hanging after logging in, you might need to increase this time.

2. Use TripleBuffering

Make sure TripleBuffering has been enabled for the driver, see #Avoid screen tearing.

Create the /etc/profile.d/kwin.sh file:

Use OpenGL 2.0 or later as rendering backend under System Settings > Display and Monitor > Compositor.

=4.8″>Modprobe Error: «Could not insert ‘nvidia’: No such device» on linux >=4.8

With linux 4.8, one can get the following errors when trying to use the discrete card:

This problem is caused by bad commits pertaining to PCIe power management in the Linux Kernel (as documented in this NVIDIA DevTalk thread).

The workaround is to add pcie_port_pm=off to your kernel parameters. Note that this disables PCIe power management for all devices.

Poor performance after resuming from suspend

If you are getting poor performance after resuming from suspend, you need to register the nvidia kernel module with the ACPI subsystem. This can be done by loading the nvidia module with the NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1 options.

This also seems to fix issues with corruption to the desktop background on resume with GNOME.

CPU spikes with 400 series cards

If you are experiencing intermittent CPU spikes with a 400 series card, it may be caused by PowerMizer constantly changing the GPU’s clock frequency. Switching PowerMizer’s setting from Adaptive to Performance, add the following to the Device section of your Xorg configuration:

Full system freeze or crashes when using Flash

If you experience occasional full system freezes using Flash, a possible workaround is to disable Hardware Acceleration:

Or, if you want to keep Hardware acceleration enabled but allowing a higher chance of screen tearing, you may try to before starting a browser:

Laptops: X hangs on login/out, worked around with Ctrl+Alt+Backspace

If, while using the legacy NVIDIA drivers, Xorg hangs on login and logout (particularly with an odd screen split into two black and white/gray pieces), but logging in is still possible via Ctrl+Alt+Backspace (or whatever the new «kill X» key binding is), try adding this in /etc/modprobe.d/modprobe.conf :

One user had luck with this instead, but it makes performance drop significantly for others:

Note that NVreg_Mobile needs to be changed according to the laptop:

• 1 for Dell laptops.
• 2 for non-Compal Toshiba laptops.
• 3 for other laptops.
• 4 for Compal Toshiba laptops.
• 5 for Gateway laptops.

Screen(s) found, but none have a usable configuration

Sometimes NVIDIA and X have trouble finding the active screen. If your graphics card has multiple outputs try plugging your monitor into the other ones. On a laptop it may be because your graphics card has VGA/TV out. Xorg.0.log will provide more info.

Another thing to try is adding invalid «ConnectedMonitor» Option to Section «Device» to force Xorg throws error and shows you how correct it. Here more about ConnectedMonitor setting.

After re-run X see Xorg.0.log to get valid CRT-x,DFP-x,TV-x values.

nvidia-xconfig —query-gpu-info could be helpful.

Blackscreen at X startup / Machine poweroff at X shutdown

If you have installed an update of Nvidia and your screen stays black after launching Xorg, or if shutting down Xorg causes a machine poweroff, try the below workarounds:

• Prepend «xrandr —auto» to your xinitrc

• Use the rcutree.rcu_idle_gp_delay=1 kernel parameter.

• You can also try to add the nvidia module directly to your mkinitcpio config file.

• If the screen still stays black with both the rcutree.rcu_idle_gp_delay=1 kernel parameter and the nvidia module directly in the mkinitcpio config file, try re-installing nvidia and nvidia-utils in that order, and finally reload the driver:

Backlight is not turning off in some occasions

By default, DPMS should turn off backlight with the timeouts set or by running xset. However, probably due to a bug in the proprietary Nvidia drivers the result is a blank screen with no powersaving whatsoever. To workaround it, until the bug has been fixed you can use the vbetool as root.

Install the vbetool package.

Turn off your screen on demand and then by pressing a random key backlight turns on again:

Alternatively, xrandr is able to disable and re-enable monitor outputs without requiring root.

Driver 415: HardDPMS

This article or section needs expansion.

Proprietary driver 415 includes a new feature called HardDPMS. This is reported by some users to solve the issues with suspending monitors connected over DisplayPort. It is reported to become the default in a future driver version, but for now, the HardDPMS option can be set in the Device or Screen sections. For example:

HardDPMS will trigger on screensaver settings like BlankTime . The following ServerFlags will set your monitor(s) to suspend after 10 minutes of inactivity:

Xorg fails to load or Red Screen of Death

If you get a red screen and use GRUB, disable the GRUB framebuffer by editing /etc/default/grub and uncomment GRUB_TERMINAL_OUTPUT=console . For more information see GRUB/Tips and tricks#Disable framebuffer.

Black screen on systems with Intel integrated GPU

If you have an Intel CPU with an integrated GPU (e.g. Intel HD 4000) and have installed the nvidia package, you may experience a black screen on boot, when changing virtual terminal, or when exiting an X session. This may be caused by a conflict between the graphics modules. This is solved by blacklisting the Intel GPU modules. Create the file /etc/modprobe.d/blacklist.conf and prevent the i915 and intel_agp modules from loading on boot:

No audio over HDMI

Sometimes nvidia HDMI audio devices are not shown when you do

For whatever reason on some new machines, the audio chip on the nvidia GPU is disabled at boot. Read more here and here

You need to reload the nvidia device with audio enabled. In order to do that make sure that your GPU is on (in case of laptops/Bumblebee) and that you are not running X on it, because it’s going to reset:

If you are running your TTY on nvidia, put the lines in a script so you do not end up with no screen.

Black screen on systems with VIA integrated GPU

As above, blacklisting the viafb module may resolve conflicts with NVIDIA drivers:

X fails with «no screens found» when using Multiple GPUs

In situations where you might have multiple GPUs on a system and X fails to start with:

then you need to add your discrete card’s BusID to your X configuration. This can happen on systems with an Intel CPU and an integrated GPU or if you have more than one Nvidia card connected. Find your BusID:

Then you fix it by adding it to the card’s Device section in your X configuration. In my case:

In the example above 01:00.0 is stripped to be written as 1:0:0 , however some conversions can be more complicated. lspci output is in hex format, but in config files the BusID’s are in decimal format! This means that in cases where the BusID is greater than 9 you will need to convert it to decimal!

ie: 5e:00.0 from lspci becomes PCI:94:0:0 .

Xorg fails during boot, but otherwise starts fine

On very fast booting systems, systemd may attempt to start the display manager before the NVIDIA driver has fully initialized. You will see a message like the following in your logs only when Xorg runs during boot.

In this case you will need to establish an ordering dependency from the display manager to the DRI device. First create device units for DRI devices by creating a new udev rules file.

Then create dependencies from the display manager to the device(s).

If you have additional cards needed for the desktop then list them in Wants and After seperated by spaces.

xrandr BadMatch

If you are trying to configure a WQHD monitor such as DELL U2515H using xrandr and xrandr —addmode gives you the error X Error of failed request: BadMatch , it might be because the proprietary NVIDIA driver clips the pixel clock maximum frequency of HDMI output to 225 MHz or lower. To set the monitor to maximum resolution you have to install nouveau drivers. You can force nouveau to use a specific pixel clock frequency by setting nouveau.hdmimhz=297 (or 330 ) in your Kernel parameters.

Alternatively, it may be that your monitor’s EDID is incorrect. See #Override EDID.

Another reason could be that per default current NVidia drivers will only allow modes explicitly reported by EDID; but sometimes refresh rates and/or resolutions are desired which are not reported by the monitor (although the EDID information is correct; it’s just that current NVidia drivers are too restrictive).

If this happens, you may want to add an option to xorg.conf to allow non-EDID modes:

This can be set per-output. See NVidia driver readme (Appendix B. X Config Options) for more information.

Override EDID

Overclocking with nvidia-settings GUI not working

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Workaround is to use nvidia-settings CLI to query and set certain variables after enabling overclocking (as explained in NVIDIA/Tips and tricks#Enabling overclocking, see nvidia-settings(1) for more information).

Example to query all variables:

Example to set PowerMizerMode to prefer performance mode:

Example to set fan speed to fixed 21%:

Example to set multiple variables at once (overclock GPU by 50MHz, overclock video memory by 50MHz, increase GPU voltage by 100mV):

Overclocking not working with Unknown Error

If you are running Xorg as a non-root user and trying to overclock your NVIDIA GPU, you will get an error similar to this one:

To avoid this issue, Xorg has to be run as the root user. See Xorg#Rootless Xorg for details.

System will not boot after driver was installed

If after installing the NVIDIA driver your system becomes stuck before reaching the display manager, try to disable kernel mode setting.

X fails with «Failing initialization of X screen»

If /var/log/Xorg.0.log says X server fails to initialize screen

and nvidia-smi says No running processes found

The solution is at first reinstall latest nvidia-utils , and then copy /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf to /etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf , and then edit /etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf and add the line Option «PrimaryGPU» «yes» . Restart the computer. The problem will be fixed.

System does not return from suspend

What you see in the log:

A possible solution based on [4]:

Run this command to get the version string:

Add the acpi_osi=! «acpi_osi=version» kernel parameter to your boot loader configuration.

Vulkan error on applications start

The factual accuracy of this article or section is disputed.

On executing an application that require Vulkan acceleration, if you get this error

Источник