[SOLVED] 'Early KMS' not working when proprietary driver installed

Maniaxx · 2018-12-19 20:36:31

I want to switch between drivers (nouveau/modesetting<>nvidia/proprietary) without uninstalling the proprietary driver. The proprietary driver works as expected. But switching to 'modesetting' lacks 'early KMS' (native resolution kicks in too late after 14secs - should be at early boot instead). I switch xorg profile and modprobe.d configs (blacklist nvidia) and re-set 'MODULES=(nouveau)' in '/etc/mkinitcpio.conf' but it doesn't seem to be activated. When i uninstall the 'nvidia' driver the 'early KMS' does work properly.

What's preventing proper 'early KMS' when 'nvidia' driver is installed? Is there a hook or something that builds-in the nvidia drivers into initramfs that get preferred by early boot udev maybe?

Linux 4.19.9-arch1-1-ARCH #1 SMP PREEMPT Fri Dec 14 00:58:26 UTC 2018 x86_64 GNU/Linux
nvidia 415.25
nvidia GTX770 (GK104/NVE0)

Edit:
I've compared dmesg and the difference is clearly visible (+10 secs) but there is no error or anything else that would explain why it is not kicking in early when 'nvidia' is installed.

dmesg-nouveau-without-nvidia-installed:

[    3.382112] fb: switching to nouveaufb from EFI VGA
[    3.382126] Console: switching to colour dummy device 80x25
[    3.382294] nouveau 0000:01:00.0: NVIDIA GK104 (0e4040a2)

dmesg-nouveau-with-nvidia-installed:

[   13.446228] fb: switching to nouveaufb from EFI VGA
[   13.446245] Console: switching to colour dummy device 80x25
[   13.446353] nouveau 0000:01:00.0: NVIDIA GK104 (0e4040a2)

The wiki says there is a KMS module for 'nvidia' but even though i have the pacman hook from the wiki installed (just rebuilds initramfs if i get it right) i do not have added any of that kernel parameters (nvidia-drm.modeset=1) nor do i have set any of these kernel modules into mkinitcpio.conf (nvidia, nvidia_modeset, nvidia_uvm, nvidia_drm).

It's weird. How can the kernel even tell that the driver is installed or not. The hdds are not even mounted. It must be something in initramfs or grub.

This are the driver PKGBUILDs:
https://git.archlinux.org/svntogit/pack … 4/PKGBUILD
https://git.archlinux.org/svntogit/pack … 4/PKGBUILD

Edit2: Solved. I've disabled the pacman hook mentioned in the wiki. Not sure how this can lead to such a behavior though. It looks like it either ignores /etc/mkinitcpio.conf or removes/ignores 'MODULES=(nouveau)' (maybe because its blacklisted?). I do not expect such 'intelligence' from mkinitcpio though. Or it was something completely different....

Last edited by Maniaxx (2018-12-19 21:53:06)

Lone_Wolf · 2018-12-20 12:43:29

I expect this has to do with mkinitcpio adding the nvidia kernel modules by autodetection and the blacklisting preventing nouveau from being loaded before nvidia.

A better solution might be to switch from /etc/modprobe.d blacklisting to blacklisting from kernel command line.
Check https://wiki.archlinux.org/index.php/Ke … and_line_2

Add something like this to the boot line for the nouveau configuration

module_blacklist=nvidia,nvidia_modeset,nvidia_uvm,nvidia_drm

The line for using nvidia would be similar, but simpler.

Last edited by Lone_Wolf (2018-12-20 12:43:48)

Maniaxx · 2018-12-20 17:18:20

Yes, that's faster indeed.

But there's one more thing:
Today i've unexpectedly ended up with late KMS again and X11 refusing to start as well. Looking up initramfs shows this:

$ lsinitcpio /boot/initramfs-linux.img |awk '/nouveau/ || (/nvidia/ && /conf/)'
usr/lib/modprobe.d/nvidia.conf
usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/nouveau.ko
etc/modprobe.d/nvidia_blacklist.conf

That's the result of a system update. There was a kernel and 'nvidia' update yesterday so 'nvidia' recreated /usr/lib/modprobe.d/nvidia.conf again (hardcoded in PKGBUILD). That's a problem. Both folders /usr/lib/modprobe.d and /etc/modprobe.d get copied into initramfs (by mkinitcpio) resulting in a double blacklist. (nvidia.conf blacklists nouveau and nvidia_blacklist.conf blacklists nvidia).

If you have the pacman.hook installed you have no chance to prevent that. Deleting /usr/lib/modprobe.d/nvidia.conf afterwards is too late already. That's what happened to me above. So, for every 'nvidia' update you would have to make sure mkinitcpio is called after you have removed the file.

Lone_Wolf · 2018-12-21 10:15:49

Hadn't expected that, fortunally there's a clean way to prevent that.

$ mkinitcpio -H modconf
==> Help for hook 'modconf':
This hook installs modprobe configuration files from /etc/modprobe.d and
/usr/lib/modprobe.d.
$

remove the modconf hook from your mkinitcpio.conf
incase there are files in those 2 folders you do want/need in the initramfs , you can add them to the FILES= array .

loqs · 2018-12-21 12:39:20

Alternatively add usr/lib/modprobe.d/nvidia.conf to pacman.conf's NoExtract

Maniaxx · 2018-12-21 18:22:32

Lone_Wolf wrote:

remove the modconf hook from your mkinitcpio.conf

That would exclude all files from these folders. You never know what future packages will install new files. Kinda dangerous i guess.

loqs wrote:

Alternatively add usr/lib/modprobe.d/nvidia.conf to pacman.conf's NoExtract

I wanted to do this in the pacman.hook at first but this is more elegant indeed. Currently i have added the 'nvidia' package to IgnorePkg.

Lone_Wolf · 2018-12-22 15:27:30

That would exclude all files from these folders. You never know what future packages will install new files. Kinda dangerous i guess.

modconf hook only job is to make those files available during initramfs .
Once system has switched to real root, the kernel can access those folders and the files in it without outside help.

There are very few kernel modules that need options / to-be-blacklisted during initramfs stage.

NoExtract is dangerous imo because software expects the not extracted files to be present, and they are not.

Maniaxx · 2018-12-22 18:35:03

There are many combinations and solutions possible here so one can pick what suits best to its own environment.

Arch Linux

#1 2018-12-19 20:36:31

[SOLVED] 'Early KMS' not working when proprietary driver installed

#2 2018-12-20 12:43:29

Re: [SOLVED] 'Early KMS' not working when proprietary driver installed

#3 2018-12-20 17:18:20

Re: [SOLVED] 'Early KMS' not working when proprietary driver installed

#4 2018-12-21 10:15:49

Re: [SOLVED] 'Early KMS' not working when proprietary driver installed

#5 2018-12-21 12:39:20

Re: [SOLVED] 'Early KMS' not working when proprietary driver installed

#6 2018-12-21 18:22:32

Re: [SOLVED] 'Early KMS' not working when proprietary driver installed

#7 2018-12-22 15:27:30

Re: [SOLVED] 'Early KMS' not working when proprietary driver installed

#8 2018-12-22 18:35:03

Re: [SOLVED] 'Early KMS' not working when proprietary driver installed

Board footer