optimus-manager icon indicating copy to clipboard operation
optimus-manager copied to clipboard

nvidia module still loads in intel mode

Open m-dwyer opened this issue 5 years ago • 5 comments

Describe the bug When running an optimus-manager --set-startup intel then rebooting, the nvidia kernel module is still loaded despite being blacklisted (see below).

My guess, given I'm running a fairly vanilla arch setup with Xorg+GNOME, is that Xorg is autoloading the module on start (maybe) after the boot process. I'm not using any custom Xorg.conf. I've also extracted and checked the contents of my initial ramdisk (/boot/initramfs-linux.img)

If I add alias <module> off for the modules listed in /usr/lib/modprobe.d/optimus-manager.conf, this stops the nvidia module loading and resolves the issue. Untested, but install <module> /bin/false would likely also work as a more aggressive way of stopping the module loading.

Unrelated, but I also had to set switching=none in /etc/optimus-manager/optimus-manager.conf, as nouveau seems to crash my system when loaded on this device.

System info

  • Arch Linux (5.2.9-arch1-1-ARCH)
  • GNOME on XOrg 1.20.5
  • GDM
  • HP ZBook Studio x360 G5 (Optimus setup -- Intel UHD 630 + Quadro P2000)

Logs


Optimus Manager (Client) version 1.1

Current GPU mode : intel
GPU mode requested for next login : intel
GPU mode for next startup : intel

$ lsmod | grep nvidia
nvidia              19103744  18
ipmi_msghandler        69632  2 ipmi_devintf,nvidia 

From /var/log/optimus-manager:

boot_setup.log

m-dwyer avatar Aug 27 '19 20:08 m-dwyer

Further comments..

I haven't gone over the code extensively, but my understanding (as someone who doesn't develop Python) is that the optimus-manager.conf blacklist file is permanent (copied in PKGBUILD), so I'm not sure on what the 'best' solution is here.

I previously made my own fedora-prime set of scripts, but this adds/removes the blacklist file.

I'm not sure where/how to determine what is loading the nvidia driver, so disabling aliases seems to be next best bet. I'm guessing this would need to be done in the daemon seeing as though the blacklist file is permanent?

Unless I'm missing something, I can't see an option to shell out to modprobe for setting aliases, and it appears this may need to be done via a config file in /etc/modprobe.d, /usr/lib/modprobe.d, etc

The nvidia-prime package used on Ubuntu also uses turns off aliases in the blacklist file for the nvidia modules. See https://github.com/tseliot/nvidia-prime/blob/cf757cc9585dfc032930379fc81effb3a3d59606/prime-select#L215

Happy to help out wherever possible (can work on it and submit a PR). I was going to redo my own set of scripts, but this app seems more relevant to Arch and more feature rich (I'm quite keen to get the power management working properly) than the quick, hacky fix I made -- and I didn't wish to reinvent the wheel.

I should also note, for my purposes I'm just using optimus-manager --set-startup and then rebooting so I can avoid having to use a patched GDM or another display manager and then losing power management, locking etc in Gnome.

I also noticed Nvidia card not visible in PCI bus errors. I haven't checked the power management yet (obviiously I'll investigate separately), but I'm assuming the device is not being powered down properly -- possibly (?) this means the nvidia card is more likely to be scanned by Xorg (or other) and the nvidia module incorrectly inserted

m-dwyer avatar Aug 27 '19 20:08 m-dwyer

The nvidia modules are indeed blacklisted by optimus-manager, and dynamically loaded by the daemon when needed. The auto-generated Xorg config should also ensure that the display server isn't picking up the Nvidia GPU in Intel mode (unless GNOME is doing something I'm not aware of).

Could you try with the latest stable version instead of the git version ?

Alternatively, try with power management disabled with this config :

[optimus]
switching=none
pci_power_control=no

This will obviously decrease battery life, but should at least help pinpointing the issue.

Askannz avatar Aug 28 '19 04:08 Askannz

I went back to the stable version in AUR which didn't make a difference. I also set switching=none and pci_power_control=no -- same issue in that the nvidia module still loads.

boot_setup.log

m-dwyer avatar Aug 28 '19 11:08 m-dwyer

Currently going through my backlog of issues and coming back to this one.

I'm still unsure what's going on here. Something we haven't checked, is the nvidia driver auto-loaded if you disable the login manager and boot straight to a TTY ? (assuming the issue is still there, of course). Just to confirm your hypothesis that it's Xorg loading up the module. But honestly that would be weird since I cannot reproduce the issue (even when I let the Nvidia card stay powered on an available throughout startup).

It'd be great if you could try with a different login manager as well.

Askannz avatar Mar 05 '20 10:03 Askannz

I was having this same issue on my system. What solves the issue for me was setting to option to disconect the GPU. Hope it helps.

image

██████████████████ ████████ benjamim@manjaro ██████████████████ ████████ ---------------- ██████████████████ ████████ OS: Manjaro Linux x86_64 ██████████████████ ████████ Host: VivoBook_ASUSLaptop X512JP_X512JP 1.0 ████████ ████████ Kernel: 5.11.6-1-MANJARO ████████ ████████ ████████ Uptime: 3 mins ████████ ████████ ████████ Packages: 1339 (pacman), 10 (flatpak) ████████ ████████ ████████ Shell: zsh 5.8 ████████ ████████ ████████ Resolution: 1920x1080 ████████ ████████ ████████ DE: GNOME 3.38.4 ████████ ████████ ████████ WM: Mutter ████████ ████████ ████████ WM Theme: Matcha-dark-sea ████████ ████████ ████████ Theme: Matcha-sea [GTK2/3] ████████ ████████ ████████ Icons: Papirus-Dark-Maia [GTK2/3] Terminal: gnome-terminal CPU: Intel i7-1065G7 (8) @ 3.900GHz GPU: Intel Iris Plus Graphics G7 Memory: 2237MiB / 15817MiB

ghost avatar Mar 23 '21 12:03 ghost

Hello @m-dwyer . Is this issue still reproducing? Were you able to give it a try enabling the option provided by the previous comment here to auto disconnect ?

Since the last update on this case was from 3 years ago, we'll keep this case opened for some days and close it if no answer is provided.

Have a nice week ahead.

nwildner avatar Jul 01 '24 10:07 nwildner