Ubuntu 24.04 hangs on Shutdown/Reboot with RTX5090

Support and Help
, ,
1

Ubuntu Version: 24.04

Desktop Environment (if applicable): XFCE

Problem Description: Hi all, I recently upgraded to a NVidia RTX5090 and since then having the following problem: when trying to reboot or restart, the machine will go through the expected procedures, which can be traced until journald stops (without relevant delay), and then, with the screen gone blank, will hang for roughly 4min20s until it eventually shuts down or reboots. The keyboard is already ‘disabled’ by that time, so SysReq does not work either. This is independent of the way I try to reboot/shutdown (via GUI dialog, via Terminal, via TTY, …). It happens with different Kernels and GPU drivers etc., pls. see below.
Only when booting with GPU drivers entirely blacklisted, shutdown & reboot behaviour is as expected.

Relevant System Information: AMD 9950X3D, Asus X870E-E Strix (BIOS 2202), Asus RTX5090 Astral OC

What I’ve Tried
Kernels tested
-6.17.0-35.35 stock
-7.0.11-1-liquorix-amd64
-7.0.12-1-liquorix-amd64
GPU drivers tested
-nouveau
-nvidia-graphics-drivers-580 (ubuntu repos)
-nvidia-graphics-drivers-595 (ubuntu repos)
-nvidia-graphics-drivers-610 (nvidia download)
Misc
-nomodeset, acpi=force, acpi=pci
-enabled/disabled several ACPI-relevant BIOS options
-tried to “manually” unload NVidia drivers on reboot/shutdown via script, but unloading failed.

I’m currently at my wit’s end - any ideas would be much appreciated!

Best,
r.

1 Like
2

Since you already tried different kernels and drivers, I would suggest checking the BIOS (=UEFI) for your board, which should be on 2306 and, if you are still comfortable with that, also the firmware for the 5090.

While I didn’t see people reporting your exact issue, the RTX5090 from a certain batch did receive reports on having problems when rebooting. The Nvidia folks have an update tool out which, according to users, does cover the 5090 and not only the 5060 cards, for which it initially arrived.

Source: https://www.nvidia.com/en-us/geforce/forums/geforce-graphics-cards/5/559505/5090-black-screen-boot-issue-still-encountered/

While the mainboard UEFI update should be a safe endeavour (modern boards are protected against problems when flashing the firmware), the GPU firmware flashing could be more risky and also require a Windows system. The hardware also is rather expensive, when compared.

So don’t feel pressured to perform those steps, but simply feel informed about, maybe some new firmware being available. :slightly_smiling_face: Perhaps go with the UEFI update first.

A more far-fetched but easy to check item would be the display cable/port. Maybe there’s some problem with the GPU getting stuck at negotiating the display mode, even at shutdown/reboot.

PS:

Welcome to the discourse forums btw :slight_smile:

4 Likes
3

Welcome to the Ubuntu Discourse @roots

So I’ve been digging around on this one and wanted to share what I found because your situation is actually more documented than it might seem.

That 4 min 20 sec hang after journald stops - that’s not random. That’s the kernel hitting its default systemd shutdown timeout waiting for the nvidia driver to cleanly unload, and it never does. The fact that blacklisting the drivers fixes it completely confirms this. You’re not doing anything wrong.

Here’s the uncomfortable truth though: this is a Blackwell (GB202) architecture bug. The RTX 5090 uses NVIDIA new GSP firmware model where a separate microcontroller on the card manages most GPU operations. On Blackwell, this GSP firmware is mandatory, you can’t disable it. And right now, it doesn’t hand off cleanly when Linux tries to power down or reset the card. Multiple open bug reports on NVIDIA’s own GitHub tracker confirm this across different GB202 systems. Your 4 different drivers, 3 different kernels, yeah, none of that was going to fix it because the problem lives deeper than the driver version.

Also just FYI, your attempt to manually unload the nvidia modules failed for the same reason. The GSP firmware holds the card in a state that blocks module removal.

Things actually worth trying:

1. Update Your BIOS first (X870E-E Strix → 2306, you’re on 2202). Low risk, and the newer revision improved PCIe power handoff behavior on X870E boards. Do this before anything else.

2. Make sure you’re running the open kernel module, not the proprietary one. For Blackwell cards the proprietary driver simply doesn’t work correctly. Check with:

cat /proc/driver/nvidia/version

Should say “Open Kernel Module” in the output. If it doesn’t, reinstall using the -open variant.

3. Add pcie_aspm=off to your kernel parameters. Edit /etc/default/grub, add it to GRUB_CMDLINE_LINUX_DEFAULT

then sudo update-grub. Not a guaranteed fix but worth testing.

4. Try adding this to /etc/modprobe.d/nvidia.conf:

options nvidia-drm modeset=1 fbdev=1

Then rebuild initramfs: sudo update-initramfs -u

Honestly though, your repro case is clean and specific (AMD 9950X3D, X870E Strix, RTX 5090 Astral OC, Ubuntu 24.04 XFCE, behavior consistent across all tested kernels/drivers). That’s exactly what NVIDIA needs. I’d strongly suggest opening a bug report at forums.developer.nvidia.com and linking to the open-gpu-kernel-modules issue tracker on GitHub. The more distinct hardware configs they have documented, the faster this gets addressed.

You haven’t missed anything. This one’s on NVIDIA

3 Likes
4

I looked into this issue and found a solution, you might want to give it a try.:

Add kernel parameters:

sudo nano /etc/default/grub

Add these to GRUB_CMDLINE_LINUX_DEFAULT:

nvidia-drm.modeset=1 nvidia-drm.fbdev=1

Then:

sudo update-grub

sudo reboot

If it doesn’t work, try upgrading to kernel 6.14+.

Hope this helps!

2 Likes
5

Hi all,

thanks for taking the time to research into this and providing such elaborate and detailed answers!

Unfortunately, none of the suggested Kernel and modprobe parameters make a difference. I’m already on the -open driver version, too. The DP cable should not be a problem, as I’m running a dual-boot installation with Win11, where reboot & shutdown are working without issues.

I will try the MB BIOS update next, and will also report the bug as suggested.

Thanks so far, I will report back as soon as I have updates!

Best,
r.

6

Hi all,

I just wanted to share a very interesting observation. I had already figured out that suspend & wake (triggered via GUI) work without issues, a bit to my surprise, tbh. Now by coincidence I just discovered, that when I reboot or shutdown some time after returning from a suspend, the PC does not hang for said 4:20 but instantly reboots or shuts down. This has been reproducible so far (5 times in a row), with the duration between wake from suspend and shutdown/reboot ranging from 3-40min.

I did not update BIOS yet and did not apply any further tweaks.

With this new situation, do you have any ideas where I may look further to debug this issue?

Best,
r.

1 Like
7

This suggests that the GSP firmware itself is likely capable of shutting down properly — it’s just that some initialization step isn’t being executed during a normal cold boot, leaving the GSP in an “unclean” state. Here’s what you can try:

1. Compare dmesg | grep -i nvidia between a normal boot and after a wake-from-suspend, and look for any extra initialization logs that appear only after waking up.

2. After a normal boot, manually run:

sudo nvidia-smi --gpu-reset

Then try shutting down — see if the hang still happens.

3. If step 2 works, you can write a script to automatically trigger the reset before shutdown as a workaround.

If none of these help pinpoint the root cause, you’re probably stuck waiting for Ubuntu 26.10.

1 Like
8

One more thing — this is not a motherboard/BIOS issue. You’ve already tried toggling ACPI-related BIOS options and it didn’t help. Your new finding (wake-from-suspend fixes it) proves it’s purely a GPU/driver initialization problem at the firmware level, not something your motherboard is doing wrong. So don’t waste any more time on BIOS settings.

9

The only difference between fresh boot and resume in dmesg | grep -i nvidia is

nvidia 0000:01:00.0: Enabling HDA controller.

I blacklisted snd-hda-intel , but it did not solve the problem.

sudo nvidia-smi --gpu-reset

obviously fails because

GPU Reset couldn’t run because GPU 00000000:01:00.0 is the primary GPU.

Tbh. my experience is too limited to come up with further ideas on my own here atm., but I’d appreciate any inputs from the community! :slight_smile:

Thanks,
r.

10

I’ve been following your debugging over the past few days. You’ve tried just about everything — and honestly, this issue is beyond what a user can solve at this point. There are only a few things left you can do:

1. Update your BIOS (but it probably won’t fix it)

2. Modify the source code (which you can’t do)

3. Wait for 26.10

4. Install a 7.2 test kernel (not recommended)

You’ve already done more than enough. The rest is up to Ubuntu 26.10.

1 Like
11

Thanks. So you’d say this is not a bug that should be filed against NVidia, as it also happens with Nouveau?

Thanks,
r.

1 Like
12

This isn’t a bug in NVIDIA’s proprietary driver — it’s a pitfall in the Blackwell GSP firmware itself. Any driver (proprietary or Nouveau) that interacts with the GSP firmware can step on this landmine. Nouveau hits a freeze when loading the GSP firmware during boot, while the proprietary driver hits a GSP non-response during shutdown — different symptoms, but the root cause is the same: the GSP firmware.

And here’s the real kicker: Blackwell doesn’t let you disable the GSP firmware at all. Only 40-series and older cards have that option.

So with the current situation, your only real option is to wait for Ubuntu 26.10 and the 7.2 kernel to be officially released. That’s where the fix is coming.

1 Like
13

Or just wait till the LTS HWE stack receives the kernel and mesa drivers of 26.10, which should be next February.

That seems to be contradictory to this being an internal issue with the GSP; what’s a new kernel going to change about that? The way I see it, that GSP is a black box and the kernel can’t change any of its inner workings.

2 Likes
14

The GSP firmware is indeed a black box — the kernel can’t change what’s inside it. But what the kernel can change is how it talks to the GSP firmware.

With the current 7.0/7.1 kernels, the NVIDIA driver simply unloads the module during shutdown without telling the GSP “I’m leaving.” The GSP still thinks the driver is running, then loses communication and gets stuck waiting. The kernel has no choice but to wait for it to time out — that’s 4m20s hang.

As far as I know,the Nova driver in Linux 7.2 changes this: during driver unload, it actively sends an UNLOADING_GUEST_DRIVER command to the GSP firmware, telling it “the driver is about to unload, clean up your state and prepare to exit.” This command is already supported by the GSP firmware interface — it’s just that no driver ever called it before.

So the new kernel isn’t fixing a bug inside the GSP — it’s fixing how the kernel interacts with the GSP. Think of it like this: current kernels are essentially yanking the power cord, while 7.2 changes it to a proper shutdown sequence.

As for why 7.0/7.1 didn’t do this — because that patch was only recently merged into 7.2 and hasn’t been released yet. That’s why to wait for 26.10.(Or wait for the 7.2 kernel to be released.)

2 Likes
15

If it’s just that, it should be possible to backport that change. I also think that @roots shouldn’t just wait but report this as a bug or, if there already is a bug report, just click the “me too” button on Launchpad to add some more heat.

Thanks to your explanation, I was able to find this pull request; the interesting bit is this:

This removes the need for a manual GPU reset between driver unbind and re-probe.

IOW, there is a way to work around this. I think some modprobe.d drop-in can help; something like this maybe:

sudo tee /etc/modprobe.d/zz-nvidia-shutdown.conf >/dev/null <<EOF
remove nvidia nvidia-smi --gpu-reset; modprobe -r nvidia
EOF
sudo update-initramfs -uk all

I don’t know — and can’t test due to lack of NVIDIA hardware — if that is the correct order.

The update-initramfs might be unnecessary, because this is only relevant on shutdown, but, to be honest, I can’t tell off the top of my head, when those modprobe.d files are read.

I suspect doing it the other way around, like modprobe -r nvidia; nvidia-smi --gpu-reset won’t work, because modprobe might block until said timeout fires. I think this should work around that:

remove nvidia sh -c 'modprobe -r nvidia & until nvidia-smi --gpu-reset; do echo die already; sleep 1; done'

(don’t know if the echo can be output at that stage but, if so, it should help see if that command works)

That’s a bit of brute force, though, because the reset command is re-run until it succeeds, endlessly if it never does, hopefully interrupted by said timeout.

3 Likes
16

Thinking about it some more, do modules even get removed explicitly on shutdown? I’d have thought that it’s just the kernel stopping itself and its last action being the power off ACPI call, or something like that.

So maybe this needs to be done another way, i.e. by a systemd service unit which gets pulled in by shutdown.target; something similar to this:

# /etc/systemd/system/unload_module_nvidia.service
[Unit]
Description=unload nvidia driver
StopWhenUnneeded=yes
After=shutdown.target

[Service]
Type=oneshot
ExecStart=sh -c 'modprobe -r nvidia & until nvidia-smi --gpu-reset; do echo die already; sleep 1; done'

[Install]
WantedBy=shutdown.target

(don’t forget systemctl daemon-reload after putting the file where the first line comment says; then run systemctl enable unload_module_nvidia)

Hopefully, the After=shutdown.target makes sure that modprobe won’t return with a “device busy” error.

Or, do a bit of both. Use the modprobe.d drop-in and just call ExexStart=modprobe -r nvidia in unload_module_nvidia.service

1 Like
17

I think your approach is on the right track conceptually — it’s essentially trying to do what the 7.2 kernel patch does. But there are a few practical issues:

1. nvidia-smi --gpu-reset already fails on his system because the 5090 is the primary GPU. NVIDIA doesn’t allow resetting the primary card.

2. Even if it didn’t fail, modprobe -r nvidia during shutdown might not even complete before the system’s timeout kicks in — since the GSP isn’t responding anyway.

3. More importantly, the UNLOADING_GUEST_DRIVER command in 7.2 is something the kernel driver sends directly to the GSP firmware. It’s not a userspace tool that can be called from a script. nvidia-smi --gpu-reset is a hardware-level reset, not a firmware-level notification.

So the idea is right, but I don’t think it’ll work in practice. Still, if someone with the hardware wants to test it, it’s worth a shot — at least it would confirm whether the workaround is viable.

1 Like
18

I think that failure is because it’s done at runtime in a normal session. Of course it won’t let the user disable their primary display driver at that stage; hence the After=shutdown.target in the systemd unit — hoping that by then it will succeed.

Why wouldn’t it? The system, by your explanation, is waiting for the device to shutdown. A missing reset seems to be the cause, so force the reset to avoid having to wait for the timeout.

So? In my book hardware level trumps firmware level.

I think you are coming up with reasons not to even try; if at first you don’t succeed, pick yourself up and try again, or however that Aliyah song went. :stuck_out_tongue:

The worst that can happen is that it results in the same outcome; perhaps with a longer timeout, because that shutdown service unit will have the default timeout setting.

Exactly. It might need some adjusting, so don’t fret if it doesn’t work the first time around, @roots. If I had the hardware to test this, I’d start with that systemd unit. If that wouldn’t work, I’d simply make that a simple ExecStart=modprobe -r nvidia and tinker a bit with the modprobe.d settings.

1 Like
19

I’m not refusing to try. Your approach actually makes sense conceptually — you’re trying to simulate what the 7.2 kernel does. But the problem is that nvidia-smi --gpu-reset simply won’t run on his machine because the 5090 is the primary GPU. NVIDIA’s driver disallows resetting the primary card — it’s not about “willingness to try,” it’s a driver-level restriction.

GPU Reset couldn’t run because GPU 00000000:01:00.0 is the primary GPU.

And to be honest, I also have an old NVIDIA card (GT 525M) from 2011. It doesn’t even come close to touching GSP firmware — and guess what? Shutdown is instant, every single time. This shows the issue isn’t that the user “hasn’t tried the right method” — it’s that the GSP firmware on new cards has its own flaws. Your logic is solid, it’s just that the hardware won’t allow it.:skull_and_crossbones:

So your idea is right — don’t get me wrong. It’s just that this particular path won’t work, and the only real option is to wait for 26.10(Or wait for the 7.2 kernel to be released).

1 Like