XMG - RTX4080 FPS drops - Linux Nobara

gems2789

New Member
Joined
May 1, 2026
Messages
4
Reaction score
1
Credits
42
Hello,
I own a XMG Neo 23 with a RTX4080 gpu. I recently switched from win10 to Linux Nobara and an issue (that I also had with windows but I solved it with whispermode in the geforce center) has reappeared on linux.
While gaming my fps drops significantly from say 60 to 3 fps and then goes back up. I already reset bios which solved some issue (notebook was stuck in low power mode) but the fps drops persist. Anybody else with that problem and solved it? Is there anything similar to whispermode that forces the gpu at a certain fps rate?

Would appreciate the help.
 


Does this happen to all games or just in one? Are they Steam games or installed using Wine/Lutris or something like that?
 
Happens with all games (was the same on windows). All steam games with Proton.

I tried several start up options but they don't work against the drops: eg.
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only DXVK_FRAME_RATE=40 %command%

MANGOHUD=1 MANGOHUD_CONFIG=fps_limit=45 gamemoderun __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only PROTON_ENABLE_NVAPI=1 %command%
 
Since you had the same problem on Windows and it happens in all games, I would not look at Proton as the first suspect. Proton can cause game-specific problems, but a drop from 60 FPS to 3 FPS across everything usually smells more like power, thermal throttling, EC/control-center profile, BIOS/firmware, or the laptop switching power states badly.

The launch options you tried mostly force the game to use the NVIDIA GPU and cap FPS. They do not really solve the root cause if the GPU or CPU suddenly drops clocks/power for a few seconds.

I would test with MangoHud and watch what happens during the drop:

Code:
MANGOHUD=1 MANGOHUD_CONFIG=gpu_stats,gpu_temp,gpu_power,gpu_core_clock,gpu_mem_clock,cpu_stats,cpu_temp,frametime,fps_limit=45,show_fps_limit gamemoderun %command%

Then check during the FPS drop:
  • Does GPU power suddenly fall?
  • Does GPU core clock suddenly fall?
  • Does CPU clock/temp spike or throttle?
  • Does GPU temp hit a limit?
  • Does the laptop switch to battery/low-power behaviour even while plugged in?
You can also run this in a terminal while the game is running:

Code:
watch -n1 nvidia-smi

If you want a log instead of watching it live:

Code:
nvidia-smi --query-gpu=timestamp,name,pstate,temperature.gpu,power.draw,power.limit,clocks.current.graphics,clocks.current.memory,utilization.gpu,utilization.memory --format=csv -l 1

I would also check the kernel log after a drop:

Code:
journalctl -k -b | grep -Ei 'nvidia|NVRM|Xid|thermal|thrott|acpi'

If you see NVIDIA Xid errors, thermal throttling, or power-state drops there, that gives a better direction.

For the WhisperMode-like part: on Linux you can cap FPS with MangoHud, DXVK/VKD3D frame limiters, Gamescope, or in-game limiters, but that is not exactly the same as NVIDIA WhisperMode from GeForce Experience. WhisperMode is more of a noise/power/thermal policy. A simple FPS cap may help reduce load, but if the laptop firmware or power profile is causing hard drops, the cap alone may not fix it.

I would start by testing one clean launch option first, not stacking everything:

Code:
MANGOHUD=1 MANGOHUD_CONFIG=fps_limit=45,show_fps_limit,gpu_temp,gpu_power,gpu_core_clock,gpu_mem_clock,cpu_temp,frametime gamemoderun %command%

If the drops still happen while capped, then it is probably not an FPS limiter problem.
 
Many thanks - I checked the parameters and you are right it was never the FPS (I suspected it but I hope it could achieve a similar outcome to geforce whispermode). 2 issues I have:
  • The NVIDIA Open Kernel Module (595.58.03) regularly loses connection to the GPU's internal GSP firmware. This directly explains the stuttering.
    NVRM: _kgspIsHeartbeatTimedOut: Heartbeat timed outNVRM: _kgspRpcRecvPoll: GSP RM heartbeat timed out

  • The GPU drops to 225–570 MHz while being almost fully utilized. That is exactly the moment of the stutter. On top of that: power.limit [N/A] — the driver cannot read/set the TDP value at all, because the SBIOS communication is failing.
    NVRM: failed to get target temp from SBIOSNVRM: failed to get platform power mode from SBIOS
Are there any easy solutions for this issue?
 
Many thanks - I checked the parameters and you are right it was never the FPS (I suspected it but I hope it could achieve a similar outcome to geforce whispermode). 2 issues I have:
  • The NVIDIA Open Kernel Module (595.58.03) regularly loses connection to the GPU's internal GSP firmware. This directly explains the stuttering.
    NVRM: _kgspIsHeartbeatTimedOut: Heartbeat timed outNVRM: _kgspRpcRecvPoll: GSP RM heartbeat timed out

  • The GPU drops to 225–570 MHz while being almost fully utilized. That is exactly the moment of the stutter. On top of that: power.limit [N/A] — the driver cannot read/set the TDP value at all, because the SBIOS communication is failing.
    NVRM: failed to get target temp from SBIOSNVRM: failed to get platform power mode from SBIOS
Are there any easy solutions for this issue?
That is no longer looking like a normal FPS limiter / Proton problem.

If you are getting:
Code:
NVRM: _kgspIsHeartbeatTimedOut: Heartbeat timed out
NVRM: _kgspRpcRecvPoll: GSP RM heartbeat timed out
NVRM: failed to get target temp from SBIOS
NVRM: failed to get platform power mode from SBIOS

and the GPU drops to 225–570 MHz while still being almost fully loaded, then the stutter is probably the symptom, not the cause. The driver/GSP/firmware/power-control path is breaking, then the GPU falls into a low clock/power state.

I would try this in order:
1. Check for the latest EC/BIOS firmware for the exact XMG Neo 23 model and exact GPU version. Be careful here, because XMG NEO E23 has different EC/BIOS files for RTX 4060/4070 vs RTX 4080/4090 models.

2. Try another NVIDIA driver branch. 595.58.03 may simply be bad on your laptop/GSP path. I have seen similar reports where 595.58.03 open kernel module had GSP heartbeat errors, while downgrading the NVIDIA stack fixed it.

3. If Nobara allows it, test the proprietary/closed NVIDIA kernel module instead of nvidia-open, and disable GSP firmware. But this is the important part: disabling GSP generally does not work while staying on nvidia-open. The open kernel module depends on GSP firmware. So if you stay on nvidia-open, adding NVreg_EnableGpuFirmware=0 probably will not help.

First check what you are actually running:
Code:
nvidia-smi -q | grep -i "GSP"
modinfo -F version nvidia
cat /etc/nvidia/kernel.conf
dnf list --installed | grep -Ei 'nvidia|dkms'

On Nobara, the documented switch from open to closed module looks like this, but do not blindly copy the driver version. Replace 580.126.09 with the version you actually have installed:

Code:
sudo sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
echo "options nvidia-drm modeset=1 fbdev=1" | sudo tee /etc/modprobe.d/nvidia-modeset.conf
echo "options nvidia NVreg_EnableGpuFirmware=0" | sudo tee -a /etc/modprobe.d/nvidia-modeset.conf
sudo chmod 644 /etc/modprobe.d/nvidia-modeset.conf
sudo dkms unbuild nvidia/580.126.09 --all
sudo dkms autoinstall
sudo dracut -f
reboot

After reboot, check:
Code:
nvidia-smi -q | grep -i "GSP"
cat /proc/driver/nvidia/version
journalctl -k -b | grep -Ei 'NVRM|kgsp|GSP|Xid|SBIOS'

If GSP shows as disabled / N/A and the heartbeat errors disappear, then the issue was likely the GSP path. If the SBIOS power-mode errors remain even on another driver branch, I would suspect EC/BIOS/ACPI firmware on the laptop side more than Proton or Steam.

I would not start with random power-limit commands like nvidia-smi -pl if the driver already reports power.limit as N/A. If the driver cannot talk properly to the platform/SBIOS power interface, forcing power limits probably will not work and may just add noise to the troubleshooting.
 
Sorry for my absence - I changed from Nobara to Bazzite as I could not change the GSP on Nobara. I did all of the above but I still get those spikes...
 

Attachments

  • Screenshot_20260514_180255.png
    Screenshot_20260514_180255.png
    2.4 MB · Views: 40
  • test3.png
    test3.png
    869 KB · Views: 48
The NVIDIA Open Kernel Module (595.58.03)
Which driver is that?

See releases below:

Start with production branch, then test with new feature branch, and if still no luck try beta driver.

The kernel version you use also matters.
It's possible driver won't build with most recent kernel, but you want to get as close as possible.
 
I use Fedora, it doesn't have these problems. Nobara claims to make life easier by by-passing some of this.
But in my experience, it makes things harder. A lot of the standard packages are not compatible with Nobara.
It's usually behind in it updates, and in the end,it's harder for me to use.

Code:
# Enable RPM Fusion
sudo dnf install \
  https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
  https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

# Enable tainted repo, update, install open drivers + CUDA + nvidia-smi
sudo dnf install rpmfusion-nonfree-release-tainted
sudo dnf update -y
sudo dnf install akmod-nvidia-open xorg-x11-drv-nvidia-cuda nvidia-smi

# Force-build kmod and regenerate initramfs
sudo akmods --force
sudo dracut --force

# Verify before rebooting — wait for version string, not an error
modinfo -F version nvidia

# Reboot
sudo reboot

That's it.. Newest drivers, automatically recompile when new kernels come out.
 
./furmark_test.sh
[ Demo Quick Stats ]
  • demo : FurMark (GL) (built-in: YES)
  • renderer : NVIDIA GeForce RTX 5080/PCIe/SSE2
  • 3D API : OpenGL 3.2.0 NVIDIA 595.71.05
  • resolution : 2560x1366
  • SCORE : 19449
  • duration : 60001 ms
  • FPS (min/avg/max) : 310 / 324 / 334
  • GPU 0: NVIDIA GeForce RTX 5080 [10DE-2C02]
.max temperature: 62�C

cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 595.71.05 Release Build (dvs-builder@U22-I3-G08-03-1) Fri Apr 24 06:42:30 UTC
2026
GCC version: gcc version 16.1.1 20260501 (Red Hat 16.1.1-1) (GCC)
rayM@blackTower1:~/Downloads/FurMark_linux64$

No dropped frames here.
 


Follow Linux.org

Members online


Top