[SOLVED] After todays upgrade dedicated Nvidia GPU won't work

MrFry · 2020-04-13 12:10:20

Hello!

After upgrading today, I restarted my laptop, and noticed that the fonts were bigger on the login screen. I immediately knew that something gone wrong with upgrading my nvidia driver. This happened a few times before, the problem is that the integrated video card is used instead of the dedicated Nvidia one.

But I have no idea what causes this, and how to debug/fix this, so I'm asking you what could have gone wrong.

Some infos

Host: Lenovo Z50-70
Linux frypc 5.6.3-arch1-1 #1 SMP PREEMPT Wed, 08 Apr 2020 07:47:16 +0000 x86_64 GNU/Linux
CPU: Intel i7-4510U (4) @ 3.100GHz
GPU: NVIDIA GeForce 840M
DE: Plasma, WM: i3
Should only use dedicated card, no bumblebee or optimus set up

Logs

cat /var/log/Xorg.0.log <- old, new one added after recent reboot
cat /var/log/Xorg.0.log

dmesg

cat /var/log/pacman.log | grep -i 'upgraded' | tail -n 200

$ cat /var/log/pacman.log | grep -i 'syu' | tail # for upgrade dates
[2020-03-22T20:50:17+0100] [PACMAN] Running 'pacman -Syu'
[2020-03-25T12:04:19+0100] [PACMAN] Running 'pacman -Syu'
[2020-03-25T18:48:51+0100] [PACMAN] Running 'pacman -Syu'
[2020-03-25T22:21:43+0100] [PACMAN] Running 'pacman -Syu'
[2020-03-27T14:48:46+0100] [PACMAN] Running 'pacman -Syu'
[2020-03-27T14:48:49+0100] [PACMAN] Running 'pacman -Syu'
[2020-04-01T15:37:03+0200] [PACMAN] Running 'pacman -Syu'
[2020-04-03T21:44:50+0200] [PACMAN] Running 'pacman -Syu'
[2020-04-13T13:10:10+0200] [PACMAN] Running 'pacman -Syu'
[2020-04-13T13:13:34+0200] [PACMAN] Running 'pacman -Syu --overwrite /usr/lib*/p11-kit-trust.so'

$ lspci
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 3 (rev e4)00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4)
00:1c.4 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4)00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)02:00.0 Network controller: Intel Corporation Wireless 3160 (rev 93)
03:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 840M] (rev a2)

$ ls /etc/X11/xorg.conf.d
00-keyboard.conf  10-nvidia-drm-outputclass.conf

$ cat 10-nvidia-drm-outputclass.conf
Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "PrimaryGPU" "yes"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

$ cat 00-keyboard.conf
# Written by systemd-localed(8), read by systemd-localed and Xorg. It's
# probably wise not to edit this file manually. Use localectl(1) to
# instruct systemd-localed to update it.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "hu"
EndSection

nvidia-smi normally reports several processes running

$ nvidia-smi
Mon Apr 13 14:27:16 2020       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.82       Driver Version: 440.82       CUDA Version: 10.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce 840M        Off  | 00000000:03:00.0 Off |                  N/A |
| N/A   42C    P8    N/A /  N/A |      0MiB /  2004MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Last time I had some problems with Nvidia:
Reddit post

I hate nvidia. Thanks! ( Happy easter c: )

Last edited by MrFry (2020-04-14 16:56:29)

V1del · 2020-04-13 12:44:31

Should only use dedicated card, no bumblebee or optimus set up

That's an inherently impossible goal, you are going to have points of interaction with Optimus technology, as your nvidia card is not connected to a display.

Xorg loads the modesetting driver instead of the nvidia driver for the nvidia card and I'm not entirely certain as to why, it looks like it loads the nvidia config way later than it should/would normally. Can you post

ls -l /etc/X11/xorg.conf.d
pacman -Qkk nvidia-utils

MrFry · 2020-04-13 12:54:40

V1del wrote:

Should only use dedicated card, no bumblebee or optimus set up
That's an inherently impossible goal, you are going to have points of interaction with Optimus technology, as your nvidia card is not connected to a display.

I might be wrong on this one, did the setup years ago. As I remember I could choose to only use dedicated card, or booth (which was more problematic, and didn't have as much performance).

$ /usr/bin/ls -l
total 8
-rw-r--r-- 1 root root 311 Mar 10  2019 00-keyboard.conf
-rw-r--r-- 1 root root 257 Apr 13 13:40 10-nvidia-drm-outputclass.conf     
$ pacman -Qkk nvidia-utils
nvidia-utils: 178 total files, 0 altered files

I tried to mess around with 10-nvidia-drm-outputclass.conf, but couldn't fix anything, so I restored it to the version it was originally

MrFry · 2020-04-13 13:10:17

With

$ uname -a
Linux frypc 5.4.31-1-lts #1 SMP Wed, 08 Apr 2020 08:29:49 +0000 x86_64 GNU/Linux
$ pacman -Q | grep nvidia-lts
nvidia-lts 1:440.82-2

everything is fine

V1del · 2020-04-13 13:12:35

Hmm can you post the lspci from the LTS kernel? The fact that your nvidia card seems to switch PCI domains might be a problem here.

MrFry · 2020-04-13 13:14:09

$ lspci
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 3 (rev e4)
00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4)
00:1c.4 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4)
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
02:00.0 Network controller: Intel Corporation Wireless 3160 (rev 93)
03:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 840M] (rev a2)

(using LTS kernel)

Last edited by MrFry (2020-04-13 13:14:52)

V1del · 2020-04-13 13:19:04

Hmm looks the same... Maybe try nailing the xorg config more explicitly?

Section "OutputClass"
    Identifier "intel"
    MatchDriver "i915"
    BusId "PCI:0:2:0"
    Driver "modesetting"
EndSection

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    BusId "PCI:3@0:0:0"
    Option "AllowEmptyInitialConfiguration"
    Option "PrimaryGPU" "yes"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

But really it looks like a weird race condition in when xorg checks it's config and the relevant kernel modules becoming available

MrFry · 2020-04-13 13:33:43

Should all of that go into 10-nvidia-drm-outputclass.conf, or the first section into a separate .conf? Tried booth, and booted to black screen.

I'm not really familiar with xorg.conf.d

Edit: when tried with separate files I named it 20-asd.conf, because I had no better idea

Edit 2 :

It did not like the BusId option:
https://bpaste.net/5P5A

I read that its BusID, but did not like that one either

Last edited by MrFry (2020-04-13 13:52:18)

seth · 2020-04-13 14:51:41

Because it belongs in the Device section

Section "Device"
    Identifier "Default nvidia Device"
    Driver	"nvidia"
     BusId "PCI:3@0:0:0"
EndSection

MrFry · 2020-04-13 15:57:09

You mean like this?

# cat 10-nvidia-drm-outputclass.conf
Section "Device"
  Identifier "intel"
  Driver	"nvidia"
  BusId "PCI:0:2:0"
EndSection

Section "Device"
  Identifier "nvidia"
  Driver	"nvidia"
  BusId "PCI:3@0:0:0"
EndSection

Section "OutputClass"
  Identifier "intel"
  MatchDriver "i915"
  Driver "modesetting"
EndSection

Section "OutputClass"
  Identifier "nvidia"
  MatchDriver "nvidia-drm"
  Driver "nvidia"
  Option "AllowEmptyInitialConfiguration"
  Option "PrimaryGPU" "yes"
  ModulePath "/usr/lib/nvidia/xorg"
  ModulePath "/usr/lib/xorg/modules"
EndSection

Xorg.0.log

seth · 2020-04-13 16:05:29

You assigned the nvidia driver (also) to the bus w/ the intel chip…

nb. that the nvidia chip is not a VGA device, do you have the output source redirection in place?

MrFry · 2020-04-13 16:47:26

seth wrote:

You assigned the nvidia driver (also) to the bus w/ the intel chip…

Yep, my bad. After changing it to intel, it still gave me a back screen.

seth wrote:

nb. that the nvidia chip is not a VGA device, do you have the output source redirection in place?

Sorry, but I don't know what you mean. As I said I'm not really good with this xorg config stuff, even after checking the wiki.

seth · 2020-04-13 16:53:13

Your thread says "After todays upgrade" - are you sure this has ever worked in the past?

You may be able to disable the intel chip in the BIOS/UEFI and have that redirect the VGA to the nvidia GPU, but if you don't you *have* to invoke the xinitrc (or otherwise, fitting your DM) from https://wiki.archlinux.org/index.php/NV … phics_only

V1del · 2020-04-13 18:24:12

Sorry about those typos/potentially wrong placements, I don't need this kind of config on any of my setups so I also have to look stuff up.

I'm fairly certain this used to work, as I was recommending the OPs existing configuration on both occasions that it came up. Regardless of whether the proper redirection takes place, I'd still assume the xorg server to initialize the nvidia X driver (albeit with potential black screen on the connected monitor) and not decide to go for modesetting so that's where I'm scratching my head currently, as to why that is the case in the first place.

MrFry · 2020-04-14 06:24:35

Following this I made these changes:

$ cat /etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf 
Section "OutputClass"
    Identifier "intel"
    MatchDriver "i915"
    Driver "modesetting"
EndSection

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "PrimaryGPU" "yes"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

I didn't have to edit /etc/X11/xinit/xinitrc or (re)install xorg-xrandr, since i made those changes a long time ago:

$ tail /etc/X11/xinit/xinitrc 
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
#exec xterm -geometry 80x66+0+0 -name login

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

xset -b

exec startkde
$ pacman -Q | grep xorg-xrandr
xorg-xrandr 1.5.1-1

I'm not sure if /etc/X11/xinit/xinitrc and ~/xinintrc are the same, ~/xinitrc does not exists now.

Results

Now it did not boot to black screen, but now we are back where we started. Some fonts are way bigger than average, and games/programs won't use nvidia card. nvidia-smi shows no processes running :c

Xorg.0.log

How come it works on LTS kernel?

Edit: Ran some xrandr stuff manually:

$ xrandr --setprovideroutputsource modesetting NVIDIA-0
Could not find provider with name NVIDIA-0
$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 4 associated providers: 0 name:modesetting
Provider 1: id: 0x1dd cap: 0x0 crtcs: 0 outputs: 0 associated providers: 0 name:modesetting

Edit 2:

Running these on LTS kernel results this:

$ xrandr --setprovideroutputsource modesetting NVIDIA-0
$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x1b8 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 1 name:NVIDIA-0
Provider 1: id: 0x1df cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 4 associated providers: 1 name:modesetting

Except the last code block everything was ran on main kernel, and I did not change /etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf or /etc/X11/xinit/xinitrc

Last edited by MrFry (2020-04-14 06:31:28)

seth · 2020-04-14 06:34:53

Ahh… we've been here before. Twice.
The xorg log in #10 loads the nvidia driver, but that doesn't find any devices (contrary to the smi output).
Your last config/log is back to the original config, thus producing the original results…

Did you ever try restarting the X11 server after the boot, resp. booting the multi-user.target and start the graphical.target by hand?
Could be a timing or crng issue (because the smi shows the GPU to be there, maybe because it's late because it's not a VGA device)

https://wiki.archlinux.org/index.php/Sy … _boot_into
https://wiki.archlinux.org/index.php/Haveged

MrFry · 2020-04-14 06:46:20

seth wrote:

Ahh… we've been here before. Twice.
The xorg log in #10 loads the nvidia driver, but that doesn't find any devices (contrary to the smi output).
Your last config/log is back to the original config, thus producing the original results…

No, because the original /etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf I used did not have this section:

Section "OutputClass"
    Identifier "intel"
    MatchDriver "i915"
    Driver "modesetting"
EndSection

Don't know if it makes any difference

seth wrote:

Did you ever try restarting the X11 server after the boot, resp. booting the multi-user.target and start the graphical.target by hand?

I'l try this

seth wrote:

Could be a timing or crng issue (because the smi shows the GPU to be there, maybe because it's late because it's not a VGA device)
https://wiki.archlinux.org/index.php/Haveged

I use rng-tools, I guess its kinda the same:

$ pacman -Q | grep rng-tools
rng-tools 6.10-1
$ systemctl status rngd.service
● rngd.service - Hardware RNG Entropy Gatherer Daemon
     Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: disabled)
     Active: active (running) since Tue 2020-04-14 08:28:16 CEST; 13min ago
   Main PID: 329 (rngd)
      Tasks: 5 (limit: 9411)
     Memory: 4.7M
     CGroup: /system.slice/rngd.service
             └─329 /usr/bin/rngd -f

Warning: some journal files were not opened due to insufficient permissions.

seth · 2020-04-14 06:57:24

Don't know if it makes any difference

Should™ be idempotent because it only enforces the behavior you've seen before (for the intel chip)

I use rng-tools, I guess its kinda the same:

Should be for most CPUs, you could still check your journal on when crng is ready.

MrFry · 2020-04-14 06:58:32

Tried this:

seth wrote:

Did you ever try restarting the X11 server after the boot, resp. booting the multi-user.target and start the graphical.target by hand?

# systemctl restart sddm

Now its cool

$ nvidia-smi
Tue Apr 14 08:52:46 2020       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.82       Driver Version: 440.82       CUDA Version: 10.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce 840M        Off  | 00000000:03:00.0 Off |                  N/A |
| N/A   47C    P0    N/A /  N/A |    536MiB /  2004MiB |     23%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      2895      G   /usr/lib/Xorg                                251MiB |
|    0      3100      G   /usr/bin/plasmashell                          14MiB |
|    0      3149      G   picom                                         52MiB |
|    0      3322      G   kitty                                          6MiB |
|    0      3954      G   ...AAAAAAAAAAAACAAAAAAAAAA= --shared-files    32MiB |
|    0      4196      G   /home/mrfry/Apps/Firefox/firefox-bin         168MiB |
|    0      5172      G   kitty                                          1MiB |
+-----------------------------------------------------------------------------+

Soo how can I skip restarting sddm every time I boot?

And
How come it works on LTS?
Why does this happen after recent upgrade?

MrFry · 2020-04-14 07:00:24

seth wrote:

Should be for most CPUs, you could still check your journal on when crng is ready.

If you mean:

$ dmesg | grep crng
[    0.105833] random: get_random_bytes called from start_kernel+0x638/0x818 with crng_init=0
[    2.422106] random: crng init done

seth · 2020-04-14 08:27:31

Yes, "mean".

So it's likely a timing issue/race condition (the rules for those are: there are no rules)

Do you have the nvidia modules in the initramfs ("lsinitcpio /boot/initramfs-linux.img| grep nvidia")?
Edit: Does it help if you move copy! them there?
https://wiki.archlinux.org/index.php/NV … de_setting

Last edited by seth (2020-04-14 08:27:52)

MrFry · 2020-04-14 16:56:00

seth wrote:

Do you have the nvidia modules in the initramfs ("lsinitcpio /boot/initramfs-linux.img| grep nvidia")?

I do now

MODULES=(ext4 crc16 mbcache jbd2 ahci libahci sd_mod scsi_mod nvidia nvidia_modeset nvidia_uvm nvidia_drm)

Added nvidia nvidia_modeset nvidia_uvm nvidia_drm to the end of the modules, and it seems to be fixed now.

nvidia-drm.modeset=1 kernel param was already added

Thank you for your help

Arch Linux

#1 2020-04-13 12:10:20