4

After upgrading from Ubuntu 20.10 to 21.10 (via 21.04, which I didn't test for suspend/resume behaviour), suspend/resume no longer works properly.

If I use the proprietary NVIDIA driver metapackage from nvidia-driver-470, the system seems to suspend ok -- using the power button (equivalent to systemctl suspend) --, but on resume, the display stays black and I have to power off to escape this.

(If I use the X.Org X Server driver, the system fails to suspend after temporarily turning off the display.)

Previously, on 20.10, suspend/resume worked ok. IIRC, I was using a proprietary NVIDIA driver.

The graphics card is a GK106GL [Quadro K4000] (codename NVE6) and the PC is a Dell Precision T5500. inxi -G output:

Graphics:  Device-1: NVIDIA GK106GL [Quadro K4000] driver: nvidia v: 470.74 
           Device-2: SHENZHEN EMEET HD Webcam eMeet C960 type: USB driver: hid-generic,snd-usb-audio,usbhid,uvcvideo 
           Display: x11 server: X.Org 1.20.13 driver: loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa 
           resolution: 2560x1440~60Hz 
           OpenGL: renderer: Quadro K4000/PCIe/SSE2 v: 4.6.0 NVIDIA 470.74

I followed some instructions for debugging kernel suspend, noting that pm-suspend (part of pm-utils) recreates the same restore failure as above, and found the following in dmesg output:

[    1.322162] PM:   Magic number: 0:486:890
[    1.322167] PM:   hash matches drivers/base/power/main.c:905
[    1.322237] pci 0000:00:1f.3: hash matches

lspci showed:

00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller

Searching for "smbus 82801ji" led me to Kernel driver i2c-i801. The source code for this driver included a fix for a resume bug. The latest kernel with the fix is 5.15-rc7.

After installing the 5.15-rc7 kernel using these instructions, restore still fails after systemctl suspend. However resume works ok after sudo pm-suspend. On 5.13, resume fails after sudo pm-suspend.

(I also tried editing /etc/systemd/sleep.conf to see if more restricted suspend options helped, but they didn't.)

glyn
  • 59

7 Answers7

1

My two cents...

Using ubuntu 20.04.1, I configured Settings -> Power -> Power Button Action to Hibernate. That didn't work well, producing a blank screen.

So I configured a Settings -> Keyboard Shortcuts -> Custom Shortcuts with a command systemctl hibernate. This works perfectly.

At the time I was having the issue I read quite a few references. I do not recall now all the information I gathered, and how I came to the conclusion my solution would be better (or simply trial and error). Imprecise the information as it may be, you might find it useful, transferring whatever you find here for hibernation to suspension.

Otherwise, simply ignore it.

sancho.s ReinstateMonicaCellio
  • 14,674
  • 11
  • 44
  • 97
0

I had the same problem after upgrade to 21.10. Graphics card GTX 970. Driver 470.74

I installed server driver 450. With this suspend is not working. Back to 470 driver. Now the system resumes.

mario
  • 21
  • 2
  • Did you really end up with 470.74? Also, have you tried 470.82 which was released yesterday? – glyn Oct 27 '21 at 18:25
  • yes, for me it's work with 470.74 last 3 days and round about 20 suspend/resume – mario Oct 29 '21 at 07:59
  • Ok, it's just surprising that downgrading and then restoring 470.74 fixes the problem, but I guess stranger things have happened. – glyn Oct 30 '21 at 07:08
  • The old problem is back. I try 470.82 from the graphics-ppa. Same behavior. Blast it off, i install nouveau-driver. That's works. And then sudo apt-get purge "nvidia*" – mario Oct 30 '21 at 17:31
  • I'm not sure I follow. Are you saying the problem recreated with 470.82? Are you also saying that you have a fix with the nouveau driver? If so, please could you write up a separate answer with the details. – glyn Nov 01 '21 at 10:13
0

A solution, of sorts, appears to be to use the X.Org X server (Nouveau display driver from xserver-xorg-video-nouveau) and delete some left-over symlinks as described in this nvidia suspend bug:

sudo rm /etc/systemd/system/systemd-hibernate.service.requires/nvidia-resume.service
sudo rm /etc/systemd/system/systemd-hibernate.service.requires/nvidia-hibernate.service
sudo rm /etc/systemd/system/systemd-suspend.service.requires/nvidia-resume.service
sudo rm /etc/systemd/system/systemd-suspend.service.requires/nvidia-suspend.service

If the above doesn't work in every case, a workaround seems to be to install the 5.15-rc7 kernel and suspend using sudo pm-suspend, although this may have some downsides.

To do this, I bound /bin/sh -c "sudo pm-suspend" to a key (the "Pause" key, "Shift"+"Break", seemed appropriate) and added the following line to the end of /etc/sudoers:

%yourusername ALL = NOPASSWD: /usr/sbin/pm-suspend

E.g.

%glyn ALL = NOPASSWD: /usr/sbin/pm-suspend

This seems to work ok. On just one occasion while using a terminal the file system containing my home directory spontaneously became read-only and needed a reboot to recover from. It is not clear whether this was a side-effect of pm-suspend, a problem in the 5.15-rc7 kernel, or something else.

glyn
  • 59
  • The problem of the file system becoming read-only has not reproduced, so I'm fairly comfortable with the workaround (although I'd prefer a fix, of course). – glyn Dec 02 '21 at 02:01
  • The same workaround applies with the 5.16.11 kernel, although the original problem isn't fixed by that kernel. – glyn Mar 02 '22 at 14:21
0

On a Legion 5 Pro 16ACH6 (Ryzen 5800H + RTX 3050 Ti) I have installed latest kernel(5.15) and I am using the on-board AMD GPU. Because I want to take advantages of the latest improvements for AMD, and because NVidia driver is not yet compatible with 5.15 kernel.

My issue was:
When I wake from suspend the external screen is black. My workaround is

  • Ctrl+Alt+F1, to access tty1 console,then
  • Ctrl+Alt+F7 to switch back to the tty7/where's the Xserver running

This way the external monitor comes back to life.

zx485
  • 2,426
razvang
  • 101
  • I tried this workaround (although with different key bindings (Ctrl+Alt+F3 for a console, Ctrl+Alt+F1 or F2 for the Xserver) and the monitor did not come back to life and I had to hard power off. – glyn Dec 14 '21 at 12:44
0

Ubuntu 21.10 NVIDIA 470/510 nv_restore_user_channels bug

Full details at: 18.04 Screen remains blank after wake up from suspend but TLDR if you see:

nv_restore_user_channels

on:

journalctl -b-1

try running:

sudo systemctl stop nvidia-suspend.service
sudo systemctl stop nvidia-hibernate.service
sudo systemctl stop nvidia-resume.service

sudo systemctl disable nvidia-suspend.service
sudo systemctl disable nvidia-hibernate.service
sudo systemctl disable nvidia-resume.service


sudo mv /lib/systemd/system-sleep/nvidia ~/nvidia.bak

and reboot.

Ciro Santilli OurBigBook.com
  • 28,474
  • Unfortunately, (for me) disabling systemd jobs no longer works on Ubuntu 21.10 and the latest kernel shipped with it (5.13.0-28-generic). It worked fine on Ubuntu 21.04. p.s I also tried other versions of the driver, including the server ones. – Max_Payne Feb 19 '22 at 09:00
  • @Max_Payne this did seem to work for me on Ubuntu kernel 21.10 5.13.0-28-generic BTW, running it right now. – Ciro Santilli OurBigBook.com Feb 19 '22 at 09:12
  • Santilli If I suspend for a couple of minutes and then resume it works, but it does not work if I try to resume the next day. On Ubuntu 21.04 with systemd fix I could keep the PC suspended for days and then resume without any problems. Switched back to Nouveau driver with Nvidia accelerating firmware. Actually everything works faster and better right now. I feel my PC much responsive. Even the font in TTY console is rendered better. Really disappointed with Nvidia... – Max_Payne Feb 19 '22 at 09:26
  • @Max_Payne BTW, I had the Exact same behavior, as mentioned at: https://askubuntu.com/questions/1032633/18-04-screen-remains-blank-after-wake-up-from-suspend/1391917#1391917 suspend only failed for longer suspends. Then I took the power cord off my laptop I managed to reproduce even on short suspend, and this fix seemed to work for short suspend as well. There might be something else different in our systems of course that leads to different behavior. It is also worth apt purge all nvidia packages if you ever try it again. – Ciro Santilli OurBigBook.com Feb 19 '22 at 10:01
  • I think it's the driver-kernel compatibility. Some people have said that on the 5.15 kernel it should work, but I prefer to stay with the Nouveau driver as I don't do gaming and it works fine for my needs. Thanks for your time. – Max_Payne Feb 19 '22 at 10:36
  • right below us a user describes the same behavior that comes after upgrading to 21.10 and solves it with Nouveau driver. https://askubuntu.com/questions/1371055/ubuntu-21-10-resume-produces-blank-screen/1391920?noredirect=1#comment2361275_1371937 – Max_Payne Feb 19 '22 at 10:43
0

I also had the same problem with Ubuntu 21.10, but my graphic card is Amd Radeon instead. I just installed mainline to upgrade kernel to 5.15.22, because I had 5.13.0. This fixed the error, I can lock and unlock the screen and shows again login window without problem. I wonder why only some devices present that problem.

mainline link: https://github.com/bkw777/mainline

thanks.

apolinux
  • 371
-1

This seems to have fixed the "resume after hibernation" issue in 22.04 as well. Resume was working fine in 20.04, for years, however right after the upgrade to 22.04 a few days ago, resume from hibernation was no longer working if the hibernation lasted for more than an hour or so. On occasion the system would just not start, other times it would start but display the initram terminal and require an fsck on the filesystem/root disk (which was scary). After this change, all testing so far as been successful (both long hibernation and short hibernation seem to work fine), nvidia drivers/opencl acceleration still works after waking up etc. My setup is more complex than average because I am running full disk encryption, including swap. Before reading this post I was starting to regret the upgrade to 22.04 :)

Ari
  • 143
  • Yeah, later kernels seem to have fixed the problem. I switched from Ubuntu to Fedora 35 then 36 beta and the problem was not present there. – glyn May 02 '22 at 06:25