Exploitr's Cubicle

Chasing a Linux Gaming Freeze: GTX 1660 SUPER, NVMe Disappears and Secure Boot

linuxnvidiagtx-1660-supersecure-bootdkmsnvmepciedebugging

This is a log of what actually happened, not a clean guide written with hindsight. I was wrong about a few things along the way.

My desktop started freezing hard, and it only began when I started playing CS2. After that, pretty much any game could trigger it. The machine is a Zorin OS 18.1 box with a Gigabyte B450M DS3H and a Gigabyte GTX 1660 SUPER.

I didn't want to start throwing parts at it, so I tried to work out what was actually breaking.

What the freeze looked like

It never died instantly. It got worse over a few minutes:

  • CPU sat around 100%, RAM looked normal.
  • Disk throughput would spike to about 3 GB/s (on a ~500 MB/s SATA drive, in one of my tests, which makes no sense) and then fall to 100-200 MB/s.
  • The game window would start acting weird or minimize itself.
  • Touching the desktop could drop the CPU from 100% to almost 0%.
  • Desktop icons disappeared.
  • Then everything froze. Reboot and shutdown didn't work, and the only way out was a hard power cycle.

All of that screamed "storage problem", so I started there.

The NVMe

My main drive was an Acer Predator GM7000 2 TB, and it clearly had issues. Any game could set off the freeze, and if I ran fio and stress-ng on it long enough, the SSD would disappear from the system and take the whole machine with it.

SMART didn't agree with me, though. No convincing media errors, nothing in the NVMe error log pointing at dead NAND. I RMA'd it anyway because it was obviously misbehaving.

Acer is still looking at it as of now.

The backup SSD

In the meantime I was using a Crucial MX500 500 GB M.2 SATA drive (CT500MX500SSD4). I was working on it, and it worked just fine with everything. SMART looked mostly fine: no media errors, though it did have 4 SATA link downshifts and 1 UDMA CRC error, which is a little suspicious but not damning.

Then I got the same full-system freeze while gaming on it.

So the Acer really was having problems, but two completely different SSDs ending up in the same freeze meant it wasn't only the Acer. Whatever this was, it was sitting above the drives.

Nothing in the logs

I went through the logs looking for the usual storage-failure stuff: NVMe timeouts and resets, SATA timeouts, link reset loops, filesystem I/O errors, machine-check and EDAC errors. Nothing matched. A dying controller usually leaves something in dmesg, but this thing could lock up completely without a clear storage error anywhere.

The GPU and the NVIDIA mess

The 1660 SUPER had some odd messages of its own:

nvidia-gpu 0000:06:00.3: i2c timeout error e0000000
ucsi_ccg i2c_transfer failed -110
ucsi_ccg_init failed - -110

Around then my NVIDIA install had turned into a mix of 595-series packages, and I'd tried the -open driver at some point. That broke multi-monitor and my resolution, so I cleaned everything out and went back to the regular proprietary driver, nvidia-driver-595 (not the -open one, and definitely not the server one).

After installing it, things got weirder. The packages were there, DKMS said the module was built, and modinfo found it. But the driver wasn't actually running. My display was stuck at 640p, and when I probed the PCIe link it was only at 2.5 GT/s:

LnkSta: Speed 2.5GT/s, Width x16

A 1660 SUPER is a PCIe 3.0 card, so it should be doing 8 GT/s. My guess is it sat at the low speed because nothing was driving it, but I didn't confirm that. What I could confirm was that the driver wasn't loading:

sudo modprobe nvidia

modprobe: ERROR: could not insert 'nvidia': Key was rejected by service

Secure Boot

So it wasn't a missing package, a failed DKMS build or a wrong path. The kernel was refusing the module because of Secure Boot.

mokutil --sb-state

SecureBoot enabled

I wanted to keep Secure Boot on. Turning it off would have "fixed" the error, but it felt like hiding the problem instead of solving it.

DKMS had the module installed (nvidia/595.91.07, 7.0.0-38-generic, x86_64: installed), and it was even signed:

modinfo -F signer nvidia

zorin Secure Boot Module Signature key

So the module existed and was signed, and the kernel still said no. The log made that clear:

secureboot: Secure boot enabled
Kernel is locked down from EFI Secure Boot mode
Loading of module with unavailable key is rejected

There was also an integrity: Error adding keys to platform keyring UEFI:db line, while the Zorin cert was being loaded from the MOK list. I checked the keyrings: the platform keyring had the Zorin key, there was a DKMS MOK entry, but the .machine keyring was empty. The kernel config had all the signature options I'd expect (CONFIG_MODULE_SIG, CONFIG_INTEGRITY_MACHINE_KEYRING and so on).

I was tempted to start editing kernel config or poking at keyrings by hand, but that seemed like a good way to make things worse, so I tried fixing the MOK enrollment first.

Re-enrolling the MOK

The Zorin MOK cert was already on disk at /var/lib/shim-signed/mok/MOK.der, and it matched the signer on the NVIDIA module. So I just imported it again:

sudo mokutil --import /var/lib/shim-signed/mok/MOK.der

After a reboot I confirmed the enrollment in the firmware's MOK Manager. The new cert showed up next to the existing Zorin one, and its key ID matched what modinfo -F sig_key nvidia reported. That was the part that finally clicked: the module is signed with the Zorin key, and now the firmware actually trusts that key.

It loads now

After that, the modules loaded normally:

nvidia_uvm           1982464  0
nvidia_drm            143360  7
nvidia_modeset       1576960  6 nvidia_drm
nvidia              100036608  75 nvidia_uvm,nvidia_drm,nvidia_modeset

nvidia-smi worked again (GTX 1660 SUPER, driver 595.91.07, CUDA 13.2), my display went back to 1080p, and the PCIe link was finally at 8 GT/s x16.

The main thing I learned is that DKMS saying "installed" means very little if Secure Boot doesn't trust the key. It looks exactly like a broken NVIDIA install when the packages are actually fine.

Where this leaves the freeze

I haven't solved the freeze. I fixed the driver problem, which was real and caused the broken display, but I haven't proven it had anything to do with the gaming freezes. The Acer was clearly misbehaving, the Crucial froze the same way, and the logs never showed a clean storage failure, so I'm honestly not sure yet what's behind it.

The next step is to go back to CS2 with the driver properly loaded and see if it still happens. At least now I'm not testing with the NVIDIA module being silently rejected in the background.

OS:             Zorin OS 18.1
Kernel:         7.0.0-38-generic
Secure Boot:    Enabled
GPU:            GTX 1660 SUPER
NVIDIA driver:  595.91.07 (loaded)
Display:        1080p
PCIe link:      8 GT/s x16 (was 2.5 GT/s before the fix)