[Solved] ThinkPad P15 Gen 2: NVIDIA RTX A3000 disappearing / Firefox "driver (null)" error on Tumbleweed

Technical Report: NVIDIA Initialization and EGL-Binding-Problems (ThinkPad P15 Gen 2)

1. System

  • Hardware: Lenovo ThinkPad P15 Gen 2 (Intel Tiger Lake-H)
  • GPU: NVIDIA RTX A3000 Mobile (Ampere GA104GLM)
  • OS: openSUSE Tumbleweed (Kernel 6.18)
  • Driver: Tested with nvidia-open-driver-G06 (580.119.02) and closed-source nvidia-driver-G06 (580.126.09)

2. Problem A: Hardware-Initializing-Error (RmInitAdapter)

After a cold start or reboot the dGPU is not found, kernel driver loaded, but graphics hardware is not “visible”.

Symptoms:

  • nvidia-smi shows: “No devices were found”.
  • dmesg shows Resource Manager (RM) error:
NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x62:0x56:2015)
NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

Cause: The Ampere-architecture uses a GSP (GPU System Processor) to reduce load on Host-Processor during initializing. On Systems with Tiger Lake-H Chipsets this can lead to a state-mismatch or timeout.

Reference: NVIDIA GSP Firmware Documentation

Solution: deactivate GSP-Firmware via Kernel boot parameter in in /etc/modprobe.d/50-nvidia.conf:

options nvidia NVreg_EnableGpuFirmware=0

verify: nvidia-smi -q | grep Firmware shows N/A for GSP.

3. Problem B: EGL-Binding / DMA-BUF Failure (driver null)

Though the driver is loaded, EGL-based Applications (for instance firefox with webrender) cannot bind the dGPU.

Symptoms:

  • Start via switcherooctl launch -g 1 firefox breaks with:
pci id for fd 23: 10de:24b8, driver (null)
  • glxgears (Legacy GLX) works, but modern EGL-applications cannot see the GPU.

Cause: Modern browsers and compositors need Kernel Mode Setting (KMS) for EGL-Handshake and buffer-sharing via DMA-BUF. Without active modesetting libglvnd cannot bind a valid vendor-path for nvidia.

Solution: activate NVIDIA DRM modesetting in /etc/modprobe.d/50-nvidia.conf:

options nvidia-drm modeset=1

4. Execution & persistence

As Tumbleweed uses Early KMS, the initrd has to be rebuild after changes:

  1. save configuration: (file: /etc/modprobe.d/50-nvidia.conf)
  2. rebuild initrd: sudo dracut -f or sudo dracut -f --regenerate-all
  3. reboot.

Result: the dGPU is correctly initialized, firefox uses hardware-acceleration (WebRender) and the GPU enters power saving mode when not in use (D3cold). Check with:

cat /sys/bus/pci/devices/0000:01:00.0/power_state

Please let me know if I made mistakes or false assumptions in my post or if something is missing. Also, if this is worth a bug report I will be glad about correct pointers to where and how I could report this. Thanks in advance.


@donmarcos Hi and welcome to the Forum :smile:

The default options are set in /usr/lib/modprobe.d/50-nvidia.conf this includes options nvidia-drm modeset=1.

I see EnableGpuFirmware: 18 via cat /proc/driver/nvidia/params so might want to check that out?

I use the rpms on Leap 16.0 with a T400, Tumbleweed I use the run files and open driver with a RTX4000…

You’re right, the system default in /usr/lib/modprobe.d/50-nvidia.conf is quite comprehensive. My mistake was naming my custom override file in /etc/modprobe.d/ exactly the same (50-nvidia.conf).

As I understand a file in /etc/ completely masks a file with the same name in /usr/lib/? So by adding my GSP-fix (NVreg_EnableGpuFirmware=0) to a new 50-nvidia.conf, I accidentally disabled the system’s default modeset=1

The ‘RmInitAdapter’ issue seems to be a specific edge case for Tiger Lake-H systems like the P15 Gen 2, which isn’t covered by the generic defaults yet.

So I moved my 50-nvidia.conf to 99-nvidia-p15-fix.conf containing only the NVreg_EnableGpuFirmware=0 fix, which works as expected.

Regarding your RTX 4000: That card is based on the Turing architecture. And as far as I know, GSP (GPU System Processor) was introduced with the Ampere architecture (like my A3000). This explains why Turing-based systems don’t run into this specific GSP-initialization timeout, as they simply don’t have that hardware component."

@donmarcos See https://download.nvidia.com/XFree86/Linux-x86_64/590.48.01/README/gsp.html AFAIK in earlier drivers it was limited support… Both my Turing GPU’s load the firmware fine.

Thank you for your reply, yes, the GSP is supported for Turing and later GPUs, but the implementation seems to differ significantly between architectures (Turing vs. Ampere).

I double-checked my system behavior. When I try to enable the GSP via:
options nvidia NVreg_EnableGpuFirmware=1

I run into the problem that the GPU isn’t initialized at all. The kernel log shows:

[   10.034409] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  580.126.09  Wed Jan  7 22:59:56 UTC 2026
[   11.038853] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x62:0x40:2661)
[   11.039529] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

As a result, the GPU is “invisible” to the OS and nvidia-smi reports No devices were found.

However, once I set NVreg_EnableGpuFirmware=0 (thus disabling the GSP and letting the CPU handle the initialization like in the older drivers), everything works perfectly and the GPU is fully active.

Would you please post the output of: nvidia-smi -q | grep GSP

I’m curious to see if your Turing GPU is actually running with GSP firmware enabled or if it defaults to “N/A”, and which firmware version it reports.

@donmarcos
Tumbleweed - Nvidia RTX4000 run files (cuda and driver)

nvidia-smi -q | grep GSP
    GSP Firmware Version                               : 590.48.01

journalctl -b | grep NVRM
Jan 21 23:10:25 kernel: NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64  590.48.01  Release Build  (dvs-builder@U22-I3-AE18-23-3)  Mon Dec  8 13:05:00 UTC 2025

Leap 16.0 - Nvidia T400 rpms

nvidia-smi -q | grep GSP
    GSP Firmware Version                               : 580.126.09

journalctl -b | grep NVRM
Jan 22 10:58:45 kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module  580.126.09  Wed Jan  7 22:59:56 UTC 2026

Thank you, I posted a bug report on the NVIDIA forums.

For anyone with the same or similar issue:
GSP failure on Ampere mobile