With the 510.54 driver, hibernation works fine. When resuming, I get a flashing cursor for a bit, then the desktop appears.
With the 510.60.02 driver, resuming from hibernation fails. I get the flashing cursor as before, but then the monitors just turn off. At this point, I can ping the machine, but I cannot login via SSH. Trying to switch to a console with Ctrl-Alt-F1/2/etc doesn’t do anything. After rebooting I don’t see anything in the logs after the start of the hibernation.
I’ve attached pre- and post-hibernate reports with the 510.54 driver, and a pre-hibernate report with the 510.60.02 driver. Obviously I can’t get a post-hibernate report with 510.60.02…
Thanks for the suggestion! I do not have the nvidia-suspend/hibernate/resume services enabled, however I do have /usr/lib/systemd/system-sleep/nvidia which AIUI performs the same job as the nvidia-resume service. I tried removing this. Unfortunately it had no effect, so I suspect this is not the issue. The linked thread talks about a kernel panic, which I do not believe I am seeing – the machine still eg responds to pings, it just seems it doesn’t get far enough through the resume process to allow any real interaction.
I have gone through the original post and it appears that with driver 510.60.02, your system is pinging but display doesn’t comes up post suspend / resume operation.
If you can ssh to machine and capture nvidia bug report with -logverbose 6 / ModeDebug “true” (prior reboot), that would be really helpful for triage purpose.
Can you also capture bug report with -logverbose 6 / ModeDebug “true” from repro state (prior reboot) and share on this thread.
Hi, I’m also having this problem on Ubuntu 22.04 with gtx 1650ti mobile, driver version 510.73.05. I attached the nvidia-bug-reports pre suspend and after suspend, with x server running with -logverbose 6 hopefully, not sure if I did it correctly. pre_suspend.gz (992.8 KB) after_suspend.gz (993.4 KB)
It’s more than just the display not coming up. As noted in the original post, I cannot SSH into the machine after resume. Possibly it doesn’t get far enough through the resume process to wake the SSH daemon. It seems that resume also doesn’t get far enough for logs etc to get persisted to disk, so I’m not sure how to get any information out that might give clues as to why resume is failing.
Also note that it is hibernate+resume that goes wrong, not suspend+resume; suspend+resume seems to work.
I can confirm that the same problem occurs on Debian 11 with kernels from 5.14 to 6.0 and drivers >510.54 (tested up to 515), with a Quadro M2200.
Since I am likewise prevented from kernel updates by this, it would be great if we could at least get a patch to 510.54 that cherry-picks the necessary changes to make it compile against newer kernel headers.