[nvidia] Screen freeze or corrupted/missing textures when switching users, switching VTs or resuming from suspend

I've seen the same issue with focal and System76 Stable PPA's 460.32.03-1pop0~1611601564~20.04~11a4029~dev nvidia packaging. All text was corrupted after waking from suspend but it has only occurred once so far.

Status changed to 'Confirmed' because the bug affects multiple users.

If you are using a Xorg session (and you probably are with Nvidia) then restarting gnome-shell might work around the problem:

1. Alt+F2

2. Type: r

3. Hit Enter

Same problem occurs for me with nvidia-driver-470. The graphical effect / issue is a bit different, yet. See attached pic... My Ubuntu 20.04 is as up-to-date as possible.

The last suggested solution is working for me (restarting gnome-shell), but this is still annoying... I've just read this : https://www.reddit.com/r/gnome/comments/k5ea3g/text_and_icon_glitching_out_after_resuming_from/ so it seems we won't have any solution before quite a long time... Fed up with nvidia !

I wonder if Nvidia has made progress on this in 510.60 since they say:

"Fixed a regression that could cause OpenGL applications to hang or render incorrectly after suspend/resume cycles or VT-switches"

[https://www.nvidia.com/download/driverResults.aspx/187162/en-us]

See also bug 1855757.

Copied the finding from https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1969142 since this bug is created long time.

Pieces of log
```
 四 14 22:55:10 kernel: NVRM: GPU at PCI:0000:01:00: GPU-581d669f-ec00-4588-ca5f-15ab24136974
 四 14 22:55:10 kernel: NVRM: Xid (PCI:0000:01:00): 13, pid=798, Graphics Exception: Shader Program Header 18 Error
 四 14 22:55:10 kernel: NVRM: Xid (PCI:0000:01:00): 13, pid=798, Graphics Exception: ESR 0x405840=0x82040000
 四 14 22:55:10 kernel: NVRM: Xid (PCI:0000:01:00): 13, pid=798, Graphics Exception: ESR 0x405848=0x80000000
 四 14 22:55:10 kernel: NVRM: Xid (PCI:0000:01:00): 13, pid=1270, Graphics Exception: ChID 0010, Class 0000c597, Offset 00000000, Data 00000000
```

For nvidia-driver, u-d-c, we need to follow
https://download.nvidia.com/XFree86/Linux-x86_64/510.54/README/powermanagement.html
to setup the parameters after some checks.

I appended the parameters:
options nvidia NVreg_TemporaryFilePath=/run
options nvidia NVreg_PreserveVideoMemoryAllocations=1

and then the problem solved.

Tried 510.60 as well and the problem is persistent.

I can confirm that adding this file fixes the problem on Ubuntu 22.04 (using Nvidia 3080 card):

$ cat /etc/modprobe.d/nvidia-power-management.conf
options nvidia NVreg_PreserveVideoMemoryAllocations=1

I did not have to set NVreg_TemporaryFilePath

With this set I can also use Wayland but that brings other problems, such as really stuttery video playback in at least firefox + youtube. So I stayed in X11 for now. Just note that 22.04 will default to Wayland with the above file present so I had to manually choose Ubuntu on X.org in the login screen.

I used a fresh install of 22.04.

Blank screen on 22.04 after upgrade. Re-installed nvidia 510 driver.

Even adding the following to /etc/modprobe.d/nvidia-power-management.conf does not fix the problem.

options nvidia NVreg_TemporaryFilePath=/run
options nvidia NVreg_PreserveVideoMemoryAllocations=1

Tried both gdm3 and lightdm, always get a black screen on resume. Using both MATE and default Ubuntu environments.

For comment#10:

NVreg_TemporaryFilePath means to use the specific path, if you didn't specify it then it will default to use /tmp. (if your /tmp has enough space to use then it's fine)

FWIK, the firefox is now from snap and the stable firefox is disable Wayland. Thus, it could be the other problem.

---

For comment#11:

Looks like the other issue, probably attach the log on a new bug report?

I tried to set both options mentioned on comment #11 and with X11 after resume I got corrupted lock screen and corrupted shell. I had to restart shell with alt+f2 and type r. Furthermore, I think this is the kind of problem the bug talks about.
I have a laptop with an option on BIOS to always use the NVIDIA card instead of hybrid approach, so in some cases laptops will be affected too because they act as desktops in this aspect.

Hi Marcos,

For bug description:
---
[Workarounds]

* Always log into a Xorg session and if corruption occurs then type: Alt+F2, R, Enter

* https://download.nvidia.com/XFree86/Linux-x86_64/510.54/README/powermanagement.html#PreserveAllVide719f0
---

It should be workaround by adding "NVreg_PreserveVideoMemoryAllocations".
Would you please share $ cat /proc/driver/nvidia/params ?

@os369510,

Here is the content of the file as requested.

```
ResmanDebugLevel: 4294967295
RmLogonRC: 1
ModifyDeviceFiles: 1
DeviceFileUID: 0
DeviceFileGID: 0
DeviceFileMode: 438
InitializeSystemMemoryAllocations: 1
UsePageAttributeTable: 4294967295
EnableMSI: 1
RegisterForACPIEvents: 1
EnablePCIeGen3: 0
MemoryPoolSize: 0
KMallocHeapMaxSize: 0
VMallocHeapMaxSize: 0
IgnoreMMIOCheck: 0
TCEBypassMode: 0
EnableStreamMemOPs: 0
EnableUserNUMAManagement: 1
NvLinkDisable: 0
RmProfilingAdminOnly: 1
PreserveVideoMemoryAllocations: 1
EnableS0ixPowerManagement: 0
S0ixPowerManagementVideoMemoryThreshold: 256
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
RegisterPCIDriver: 1
EnablePCIERelaxedOrderingMode: 0
EnableGpuFirmware: 18
EnableDbgBreakpoint: 0
RegistryDwords: ""
RegistryDwordsPerDevice: ""
RmMsg: ""
GpuBlacklist: ""
TemporaryFilePath: "/run"
ExcludedGpus: ""
```

Hi Macros,

would you please share the output of `journalctl -b` when issuing happening?

I executed 'journalctl -b -f' to get the logs (they are in the file) and executed systemctl suspend.

I've seen most people talking about the first solution that Nvidia documents, which is probably slow:

  "Save allocations in an unnamed temporary file"

The faster solution would be:

  "S0ix-based power management"

Both are documented in https://download.nvidia.com/XFree86/Linux-x86_64/510.54/README/powermanagement.html#PreserveAllVide719f0

I think this highlights why the bug exists in the first place -- keeping Nvidia GPU memory alive during sleep requires more power than the GPU would usually receive (or that you would like it to use) in a sleep state.

Daniel: Desktop motherboards usually do not support "S0ix-based power management" so the other option is the only viable one for desktops.

I'm using a RTX 3080 Ti on a Z690 Desktop motherboard and enabling the S0ix option fixed the problem for me.

I've added the following option "nvidia.NVreg_EnableS0ixPowerManagement=1" to GRUB_CMDLINE_LINUX_DEFAULT.

Unfortunately nvidia.NVreg_EnableS0ixPowerManagement=1 did not work on an old Asus Rog Maximus VIII mobo (Kabylake), nvidia 1650.

I also tried this:
/etc/modprobe.d/nvidia-power-management.conf
options nvidia NVreg_PreserveVideoMemoryAllocations=1

and it didn't work either. Missing textures after suspend. Any other hint?

Try nvidia.NVreg_PreserveVideoMemoryAllocations=1 as suggested by @vanvugt

You may wanna change the file path of the temporary file thought for better performance.

@Sebastian adding both the kernel parameter and the two lines in the nvidia module conf file works for "systemctl suspend" - the machine can now resume OK when on wayland.

Curiously though, when I try systemctl suspend-then-hibernate (my default way of suspending), I get the following in dmesg:

NVRM: GPU 0000:02:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.

and the machine does not suspend (I get a login prompt after 30 seconds or so). After this issue is triggered once, "systemctl suspend" also seems to break until the next reboot.

Note that "systemctl hibernate" works fine on wayland and Xorg. Also, on xorg, systemctl suspend-then-hibernate also works fine.
Could this be a bug on systemd?

>adding both the kernel parameter and the two lines in the nvidia module conf file works for "systemctl suspend" - the machine can now resume OK when on wayland.

I've tried this solution. There's a chance I've done it wrong though.

cat /etc/modprobe.d/nvidia-power-management.conf
options nvidia NVreg_TemporaryFilePath=/run
options nvidia NVreg_PreserveVideoMemoryAllocations=1

AND:

cat /etc/default/grub | grep "CMD"
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia.NVreg_EnableS0ixPowerManagement=1"
GRUB_CMDLINE_LINUX=""

Upon systemctl suspend the monitor loses connection then gets its back after about 30 seconds and shows the login screen.

@robswc

I understand what you mean. I get the solution from this page:
https://forums.developer.nvidia.com/t/trouble-suspending-with-510-39-01-linux-5-16-0-freezing-of-tasks-failed-after-20-009-seconds/200933/12?u=user126177
I don't even need anyone of these configurations, just the method indicated in the post.

@mhalano

I actually just found that too!

Its amazing. I've since put it here:

https://github.com/robswc/ubuntu-22-nvidia-suspend-fix-script/blob/main/README.md

To quickly run through the steps for my other PCs.

Dear Mr Bug Watch Updater: If you are referring to https://gitlab.gnome.org/GNOME/mutter/-/issues/1942 then I would like to inform you that it was closed without fixing and the problem still remains so please explain in what way the fix is released.

Thanks.

'Fix Released' is the only supported closed state for upstream bug tasks, even when an upstream bug is closed without a fix.

'nvidia-wayland' means a bug only happens on Wayland, which this does not.

We use the 'wayland' tag to indicate that a bug can occur on Wayland, which was already done in comment #9.

Status changed to 'Confirmed' because the bug affects multiple users.

nvidia 440 etc are EOL

This sounds relevant:

> This threshold can be set to 0 in order to prevent the video memory from being turned off.

https://download.nvidia.com/XFree86/Linux-x86_64/535.129.03/README/dynamicpowermanagement.html#VidMemThreshold

Daniel, I tried setting that threshold to zero but it made the desktop apps unstable after coming back from resume (Nvidia 3080Ti). Maybe it doesn't work on desktop GPUs. So I went back to the solution I wrote about in comment 10. Maybe that solution should be used to solve this problem? It looks like it is already used in e.g. Tumbleweed.
Thanks.

Yes the solution in comment 10 is indirectly mentioned above in [Workarounds], but it's not very obvious:

https://download.nvidia.com/XFree86/Linux-x86_64/510.54/README/powermanagement.html#PreserveAllVide719f0

I think we have some options to fix this. Yet, which would be a solution that could be packaged? If I understand https://download.nvidia.com/XFree86/Linux-x86_64/510.54/README/powermanagement.html correctly there are the following options:

Keep the GPU-Memory Running
===========================

Pro:
* Only need to set a kernel module parameter
Con:
* Only works in S2
* Uses more power than necessary (at least if more than 256 MB graphic memory are used)
* Does not work with suspend-to-disk (at least if I understood things right)

Copy Memory to tmpfs
====================

Dump the graphic-memory into tmpfs. I wouldn't suggest using /run, but creating a driver-specific tmpfs that is large enough to hold the graphic memory.

Pro:
* Just works, as the kernel takes care of paging the tmpfs to disk in case of stand-by or suspend-to-disk.
Con:
* Delayed suspend and wakeup
* Unexpected swap-usage -> OOM-Killer might kick in on suspend if there is not enough or no swap.

Get everyone to work around it
==============================

Get all the affected applications to update their video-memory after suspend-to-X.

Pro:
* Does not have any of the Cons of the other solutions
Con:
* Probably very tedious.

Keep it as it is
================

Pro:
* Minimal effort
* Kind of works most of the time.

Con:
* Nobody is really happy.

Comments?

> Comments?

I'd vote for "Copy Memory to tmpfs".

Doing nothing is clearly not the right solution.

Comment #35 does not list all the options. We could also just fix Mutter so that it detects when textures need refreshing and do so. It already has the logic to do this, but it's clearly not hooked up in enough places.

The reason this bug gets ignored so much is because it generally only affects Nvidia desktops and only those that are put to sleep. And even then it doesn't happen reliably. In the past when I tried testing it I found on most attempts the bug didn't happen. So like with so many bugs, it just needs a developer who can reproduce it and has the time to fix it.

I hit the issue, in Wayland only.

Adding of "options nvidia NVreg_PreserveVideoMemoryAllocations=1" into /etc/modprobe.d/nvidia-graphics-drivers-kms.conf and running "sudo update-initramfs -u" (not sure it's needed) + reboot helped me. Now when I resume my PC from the suspend mode, then a desktop wallpaper and menus/fonts are correct.

Tested with HW: MSI RTX 4060, SW: nvidia 560.31.02, Ubuntu 24.04

We cannot just globally enable NVreg_EnableS0ixPowerManagement as, per nvidia's documentation, it requires that "both the platform and the GPU support S0ix-based power management", which my card does not for example.
It might be harmless to enable it even if the card does not support S0ix, but it wouldn't solve the issue for everyone.

Unfortunately, NVreg_PreserveVideoMemoryAllocations is currently broken in kernel 6.11, manifesting with an completely unresponsive system upon resume (some people say online they could at least ssh into the system, but I couldn't even do that; it might depend on the status of the network card).
NVreg_PreserveVideoMemoryAllocations is also broken with kernel 6.8 but only when using the 560 driver, which is the new default in Oracular...

In the future the plan is to turn on NVreg_PreserveVideoMemoryAllocations by default.
But at the moment we're better off with the feature disabled: at least when resuming from sleep the system is still responsive.

It’s also possible to fix in mutter/gnome-shell without changing drivers. We just need more things connected to the gl-video-memory-purged signal.

Adding a gtk4 task because the same issue was reported in Nautilus too.

Status changed to 'Confirmed' because the bug affects multiple users.

The note in the summary is not quite correct: "And even then, only desktops that use suspend/resume and VT switching may trigger it, if ever."

In my case, it happens after any suspend / resume cycle, without ever switching VT (or user).

Thanks for pointing that out. I've now corrected the text:

- suspend/resume and VT switching
+ suspend/resume or VT switching

I did a review of the Mutter code today and tested it on Nvidia 570. Indeed NV_robustness_video_memory_purge isn't wired up for EGL (Wayland) like it is for GLX (Xorg). But also it seems to behave quite differently. So rather than being a quick fix this may become an exercise in waiting for full ARB_robustness support in some future Mutter version.

Prototype (not working):
https://gitlab.gnome.org/vanvugt/mutter/-/commits/egl-robustness

It appears Xorg sessions are good at avoiding this bug now. The only problem you might encounter is if you log out, because in Ubuntu 24.10 and later the login screen doesn't use Xorg so will be just as broken as a Wayland session. To avoid the problem in both cases you can uncomment 'WaylandEnable=false' in /etc/gdm3/custom.conf

To fix the Wayland case it is still looking like we should pursue NVreg_PreserveVideoMemoryAllocations and just fix the Nvidia driver. Although longer term, Mutter is still expected to be fixed when it gains OpenGL "robustness" support.

NVreg_PreserveVideoMemoryAllocations behaves well with the 570 driver and kernel 6.14 as in plucky.

Because it works by dumping the allocated memory to a filesystem, here are the edge case scenarios to consider:

1) If NVreg_TemporaryFilePath points to disk-backed storage and the free space on the filesystem is not enough to hold the entirety of the GPU memory used, unpon resume the nvidia-drm driver fails with:

nvidia-modeset: ERROR: GPU:0: Failed to bind display engine notify surface descriptor: 0x1a (Ran out of a critical resource, other than memory [NV_ERR_INSUFFICIENT_RESOURCES])
nvidia-modeset: ERROR: GPU:0: Failed to allocate display engine core DMA push buffer
nvidia-modeset: ERROR: GPU:0: Failed to bind display engine notify surface descriptor: 0x1a (Ran out of a critical resource, other than memory [NV_ERR_INSUFFICIENT_RESOURCES])
nvidia-modeset: ERROR: GPU:0: Failed to allocate display engine core DMA push buffer
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state
[drm:__nv_drm_connector_detect_internal [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00002900] Failed to detect display state

2) If NVreg_TemporaryFilePath points to tmpfs and the free space on the filesystem is not enough, unpon resume we're presented with the same issue as (1). This is solvable by creating an ad-hoc tmpfs that is guaranteed to be as big as the sum of all NVIDIA GPUs' memory, but then we might enter issue (3).

3) If NVreg_TemporaryFilePath points to tmpfs and the free system memory+swap space is not enough, the system hangs while trying to enter sleep and the only option is to force reboot.

For desktop users this is arguably not much worse than the status quo.
However, for laptop users (where the primary GPU is the integrated one) enabling NVreg_PreserveVideoMemoryAllocations risks worsening the experience if they hit the analyzed edge ca...

It's important to remember desktops are the main issue here. I don't think it's a big ask that if you have a machine with an Nvidia card then we require $gigabytes of disk space to be reserved. Alternatively we can just inhibit suspend in the case that insufficient space is available just-in-time.

For the laptop use case where Nvidia is the secondary GPU it's less likely any Nvidia GPU memory is in use at all (though don't forget https://gitlab.gnome.org/GNOME/mutter/-/issues/3550). Because most apps will be running on the primary (integrated) GPU by default, and all of the shell will be too. So then it's just an app corruption issue and not whole shell corruption.

Overall the edge cases sound pretty good to me. Imagine the percentage of bug reports here that will be eliminated by having suspend/resume working for most people most of the time.

> For the laptop use case where Nvidia is the secondary GPU [...] it's just an app corruption issue and not whole shell corruption.

I don't have the hardware to test but I expect all further app launches on the dGPU to be broken following the driver entering a broken state (it is unable to resume operating a display, I'm not sure whether it would still be able to do off-screen rendering).

In any case, by your comment I take that you would avoid option 3 (large tmpfs which would otherwise risk overflowing the RAM+Swap space and hang the system irrecoverably). Then, what do you think of using /tmp (which is a tmpfs with size 50% of the system memory) versus writing to disk directly?

I don't think it's a good gamble that 50% of system memory will always be enough when modern games use basically 100% GPU memory. That's likely a significant proportion of system memory. Or that 50% of system memory will always be available and that swap can grow large enough after that.

We absolutely want the performance advantage of system memory over disk, but reliability comes first. Also the Linux kernel tends to allocate most unused RAM to the disk cache (mine is presently 52GB of 64GB), so if your machine does have enough spare RAM then using the disk will be nearly as performant as RAM.

Proposed: https://github.com/canonical/nvidia-graphics-drivers/pull/73

"Won't Fix" for mutter and gnome-shell because the driver fix will land so much sooner than we can get context robustness into Mutter. When and if that arrives it will be to solve other issues, not this one anymore.

GTK4's backend changes more frequently than I can keep up. Do we still need a task for that here?

Here are my findings on GTK4 when testing on GNOME-Xorg without the driver-side fix.

The NGL backend shows graphical corruption when resuming (but eventually resolves itself when presumably something causes the textures to be reloaded from disk), while the Vulkan backend breaks up completely with:

  vkGetFenceStatus(): The logical or physical device has been lost. (VK_ERROR_DEVICE_LOST) (-4)

As expected, no issues with GTK4 applications when using the driver-side fix instead.

That's good news and bad news. Thanks.

Fix committed to https://github.com/canonical/nvidia-graphics-drivers/pull/73, but not committed to proposed yet.

Now in questing-proposed: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-570/570.153.02-0ubuntu5

Fix Released in 570.153.02-0ubuntu7

Should we expect the fix to work its way back to LTS releases over time? If so then I will rearrange the tasks here again to show it.

> Should we expect the fix to work its way back to LTS releases over time?

Not automatically. We could, but I feel like this is a large change, and I previously had trouble (comment #39) with kernels 6.8 and 6.11 that are shipping in noble and jammy for non-HWE.

Given how broken the original bug here is, perhaps a failure to resume on older LTS kernels is OK. At least HWE LTS machines could have the fix.

The LTS's default to Xorg, so if restore works on Xorg then this risks being a regression for the default experience users.

OK, good point. Let's say this is only fixed in 25.10 and later. That makes sense given 26.04 will be the first LTS where we actually recommend and default to Wayland on Nvidia.

What about pushing it to 25.04, so that more users test it before the release of 25.10?

Also, is my understanding correct that one can implement the fix by adding these lines in /etc/modprobe.d/nvidia-graphics-drivers-kms.conf?

# Preserve video memory on suspend/resume
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var

> Also, is my understanding correct that one can implement the fix by adding these lines in /etc/modprobe.d/nvidia-graphics-drivers-kms.conf?
>
> # Preserve video memory on suspend/resume
> options nvidia NVreg_PreserveVideoMemoryAllocations=1
> options nvidia NVreg_TemporaryFilePath=/var

Yes

Also in proposed here:
https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-575/575.64.03-0ubuntu2

The fix is present in 580 for Questing, but not in 580 for Plucky or Noble. Also annoying that Launchpad won't let me add a Plucky task to show this.

Also reported to GTK as a backup solution in case the driver fix doesn't work for some combinations:
https://gitlab.gnome.org/GNOME/gtk/-/issues/7794

Can someone check if new systems being certified with Noble are shipping with any GSK_RENDERER set in their environments?

The status values for gnome-shell and mutter need some explaining.

Early support for NV_robustness_video_memory_purge was implemented in mutter and gnome-shell for Xorg sessions about a decade ago. I later filled in the missing pieces for mutter so consider it done for Xorg. But the same fixes don't work for Wayland (as mentioned in comments 45-46).

So although the same Xorg fix exists in all supported Ubuntu releases, it is only relevant to releases that default to or might be certified on Xorg: 24.04. We consider later releases as unfixable in the compositor because they use Wayland only.

The gtk4 task is in a similar position. Although support for NV_robustness_video_memory_purge does not seem to have ever existed in GTK, it would only ever be required in 24.04 where there's a chance the bug hasn't already been fixed in all the Nvidia drivers.

Status changed to 'Confirmed' because the bug affects multiple users.

Reply #69,

I am not sure how many places should I check, is /etc/environment and all systems service config enough. And how to confirm the app has it or not when it is launched by the launcher.

OEM team had never add special config with GSK_RENDERER variable for OEM preload image.

I just mean open a terminal and run:

  echo $GSK_RENDERER

@vanvugt, on a stock Ubuntu with 580.65.06 nvidia driver, no.

This bug was fixed in the package nvidia-graphics-drivers-580 - 580.95.05-0ubuntu0.24.04.2

---------------
nvidia-graphics-drivers-580 (580.95.05-0ubuntu0.24.04.2) noble; urgency=medium

  * New upstream release 580.95.05 (LP: #2125754)
  * Preserve video memory on suspend/resume (LP: #1876632)

 -- Kuba Pawlak <email address hidden> Wed, 01 Oct 2025 11:17:48 +0200