Is the order of NVIDIA kernel modules in mkinitcpio important?

xtian · 2017-11-18 22:41:11

Background: I'm troubleshooting backlight using the new `nvidia-lts` (v387.22) package. I'm revisiting all the install steps, including my install of Bumblebee and a fix for screen tearing with NVIDIA cards [1]. I ran across an outside page on Bumblebee describing an issue (c. 2016-07) with the Nvidia card being always "on".

My post isn't about this issue, but rather a comment in the text:

"Turning Off Nvidia Manually
First, let's try to shutdown Nvidia by hand. To be sure that we're facing with the issue described here; three modules must be listed exactly in the same order like in this example:
sudo rmmod nvidia_drm nvidia_modeset nvidia
sudo tee <<<OFF /proc/acpi/bbswitch

--> exactly the same order?

I entered the MODULES into `mkinitcpio.conf` as instructed [2].

MODULES="ext4 dm_mod dm_crypt vfat nvidia nvidia_modeset nvidia_uvm nvidia_drm"

Yet, the wiki page just lists those modules in a casual way--doesn't provide a code snippet; doesn't warn about the order. And the fact is I don't know if kernel module order is important for the nvidia KMS modules. (I know mkinitcpio HOOKS go in order, ie. LUKS). I'm hoping someone can enlighten me about NVIDIA modules,

Is the order of NVIDIA kernel modules in mkinitcpio important?

What's more, I get an error when I try to turn off the NVidia modules (I get the same error in X, and in the console):

$ rmmod nvidia_drm nvidia_modeset nvidia
rmmod: ERROR: Module nvidia_drm is not currently loaded
rmmod: ERROR: Module nvidia_modeset is not currently loaded
rmmod: ERROR: could not remove 'nvidia': Operation not permitted
rmmod: ERROR: could not remove module nvidia: Operation not permitted

+++
[1]

Tearing/Broken VSync
This requires xorg-server 1.19 or higher, linux kernel 4.5 or higher, and nvidia 370.23 or higher. Then enable DRM kernel mode setting, which will in turn enable the PRIME synchronization and fix the tearing.”

[2]

DRM kernel mode setting
nvidia 364.16 adds support for DRM kernel mode setting. To enable this feature, add the nvidia-drm.modeset=1 kernel parameter, and add nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm to your initramfs#MODULES.

Last edited by xtian (2017-11-18 23:03:19)

seth · 2017-11-19 08:54:57

That is what depmod is there for and thus "modprobe" ( -r, unlike rmmod) handles dependencies automagically. Also rmmod doesn't "force" anything, "rmmod -f" does. So much for Antergos....

Also the modules seem not to be loaded (what's pretty normal for bumblebee) - don't blindly copy and paste shit from the interwebz, check and compare the actual state to the intended one (in this case, lookup lsmod to know the state of the system) and act accordingly.

V1del · 2017-11-19 11:37:22

You also seem to be very confused on the relation of Intel/Nvidia GPU's and what Optimus is. My comment wrt to backlight, and the AUR package nvidiabl would only be relevant if the Nvidia GPU was the only and display driving card in your system On Optimus systems that isn't the case, your (laptop) display is hooked up to the intel card, so the intel card controls your backlight (unless you have a laptop that allows you to disable Optimus in the BIOS/UEFI). Furthermore if you use Bumblebee, then follow the bumblebee article, none of the modprobe/mkinitcpio/screen tearing setup/kernel module parameters are going to be relevant if you run a Bumblebee setup, which will use the internal card for most of the rendering work, and only activate the Nvidia card on demand. If you were to move that to a PRIME/Optimus/nvidia main render setup, and the information on how to do that is listed on the Optimus page, you'd have to remove all of the setup regarding Bumblebee, since the two are mutually exclusive.

This still wouldn't change the fact that backlight is handled by the intel GPU, so remove nvidiabl and the kernel parameter I mentioned if you added that.

This whole series of threads is a mess, you should've continued in your original thread if your goal is still to fix the backlight, now you've done god knows what in an attempt to fix the issue and creating threads for the wrong bits and pieces along the way you not only have an XY problem, you have an UVWXYZProblem.

If you really intend to properly resolve this: Define what you want: Run standard applications on power saving intel and only use nvidia on demand, or run everything on the nvidia card. Then make a new thread containing the full untruncated outputs of

dmesg
pacman -Qs bumblebee
pacman -Qs nvidia
glxinfo | grep OpenGL
systemctl status bumblebeed.service
groups
ls -l /sys/class/backlight/
lsmod

As well as the configuration files for xorg in /etc/X11/ and the startup files for your session ~/.xinitrc if you don't use a DM

Last edited by V1del (2017-11-19 16:46:42)

xtian · 2017-11-21 09:55:39

@V1del - Sorry if my post has caused you any consternation. I am certainly on a journey of discovery. Thank you for your advise. You've given me a lot to think about.

xtian · 2017-11-26 00:09:42

@V1del,
I was thinking about your response. I am confused, but not about what I want, or how to follow clear instructions. I'm confused about which packages I need to get necessary functionality (I can't use my laptop until I can adjust that backlight--it's at 100% all the time).

When I started, I was ready to be happy with just an Nvidia config; It seemed easiest. (My laptop is just for programming projects, I don't need heavy graphics, I'm only using it corded at a desk.) But, when I couldn't get the backlight to work, I had to try other configurations.

Me and my Nvidia Optimus hardware are like a guy who has 4-Wheel drive sedan. I know what it is. I know when it's useful. But I don't know how to repair the drivetrain when the wheel is pulling to the right. What I do know how to do is get a Chilton's Repair Manual and follow the instructions.

One thing all of those great repair manuals have is a symptoms table--
IF this is happening, THEN this could be the problem.

In this case, one of the biggest problems is the nature of any config--Super multi-dimensional contingencies!
You should do "x" unless your particular usecase makes "x" unnecessary. Nvidia Optimus and its related solutions is no stranger to this language.

One solution could be a crowd-sourced HTML table of Use Cases and their Solutions.

For example, here's something I threw together in my Google Sheets: Archlinux Nvidia Optimus

Is that something you might be interested to contribute to?

If it collects enough useful solutions, I could work to steward it's addition to the Wiki. My open source contribution, right? Baby sitting some installation documentation.

Last edited by xtian (2017-11-26 00:19:38)

Arch Linux

#1 2017-11-18 22:41:11

Is the order of NVIDIA kernel modules in mkinitcpio important?

#2 2017-11-19 08:54:57

Re: Is the order of NVIDIA kernel modules in mkinitcpio important?

#3 2017-11-19 11:37:22

Re: Is the order of NVIDIA kernel modules in mkinitcpio important?

#4 2017-11-21 09:55:39

Re: Is the order of NVIDIA kernel modules in mkinitcpio important?

#5 2017-11-26 00:09:42

Re: Is the order of NVIDIA kernel modules in mkinitcpio important?

Board footer