Suspending to RAM freezes computer

[Jarno Suni]

When I try to suspend, it does not work: fans keep spinning, but just screen blanks and computer does not respond to keyboard. 'journalctl -b -1' does not tell anything suspicious after shut down - start. This used to work. Might not be reproduceable always.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-65-generic 5.4.0-65.73
ProcVersionSignature: Ubuntu 5.4.0-65.73-generic 5.4.78
Uname: Linux 5.4.0-65-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: jarnos 1014 F.... pulseaudio
 /dev/snd/controlC2: jarnos 1014 F.... pulseaudio
 /dev/snd/controlC0: jarnos 1014 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
Date: Sun Feb 28 23:57:02 2021
InstallationDate: Installed on 2020-05-03 (301 days ago)
InstallationMedia: Xubuntu Core 20.04 - amd64 - 20200423
IwConfig:
 lo no wireless extensions.

 enp3s0 no wireless extensions.
MachineType: Dell Inc. OptiPlex 745
ProcFB: 0 nouveaudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-65-generic root=UUID=f2d9359d-8b8e-46c4-9f37-452c3dd06417 ro
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-65-generic N/A
 linux-backports-modules-5.4.0-65-generic N/A
 linux-firmware 1.187.9
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/26/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 2.6.6
dmi.board.name: 0RF703
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 6
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr2.6.6:bd06/26/2011:svnDellInc.:pnOptiPlex745:pvr:rvnDellInc.:rn0RF703:rvr:cvnDellInc.:ct6:cvr:
dmi.product.name: OptiPlex 745
dmi.sys.vendor: Dell Inc.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Guilherme G. Piccoli (gpiccoli)]

Hi Jarno, can you please confirm if that behavior you observed is not explained by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1885085 ?

Thnaks!

[Jarno Suni (jarnos)]

Hi Guilherme, I have mixed result:

$ LC_ALL=C sudo journalctl | grep "PM: suspend" | tail -n 17
Sep 22 11:19:52 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)
Sep 22 11:20:14 jarnos-OptiPlex-745 kernel: PM: suspend exit
Sep 22 11:20:14 jarnos-OptiPlex-745 kernel: PM: suspend entry (s2idle)
Sep 22 11:20:36 jarnos-OptiPlex-745 kernel: PM: suspend exit
Sep 22 11:21:26 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)
Sep 22 11:30:00 jarnos-OptiPlex-745 kernel: PM: suspend exit
Dec 04 15:53:23 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)
Dec 04 17:50:48 jarnos-OptiPlex-745 kernel: PM: suspend exit
Dec 04 18:40:19 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)
Dec 04 18:50:02 jarnos-OptiPlex-745 kernel: PM: suspend exit
Dec 04 19:35:56 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)
Dec 05 01:07:52 jarnos-OptiPlex-745 kernel: PM: suspend exit
Feb 14 14:52:33 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)
Feb 20 22:59:47 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)
Feb 21 14:21:38 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)
Feb 21 18:43:59 jarnos-OptiPlex-745 kernel: PM: suspend exit
Feb 28 23:32:29 jarnos-OptiPlex-745 kernel: PM: suspend entry (deep)

[Guilherme G. Piccoli (gpiccoli)]

Thanks Jarno. Can you run a test with them? Force one method to be used (like "deep"), following the commnad-line option in LP #1885085, and run 10 tests...5 of them after a reboot.
After that, force the other and re-run the tests. Let's see if we can narrow your issue to one suspend method.

Thanks!

[Jarno Suni (jarnos)]

According to above, exiting suspend has failed only in deep mode, but I wonder why there is one s2idle mode. Maybe later I rub some tests.

[Guilherme G. Piccoli (gpiccoli)]

Can you also attach the syslog? Thanks!

[Jarno Suni (jarnos)]

I tried a couple of times. It does not work no matter which mode I use.

[Guilherme G. Piccoli (gpiccoli)]

OK, please attach /var/log/{kern.log,syslog} so we can take a look, we may need to run some experiments. Also, do you have a working version? Like "in version X it *always* works, starting in kernel version Y, it's flaky".

Cheers,

Guilherme

[Jarno Suni (jarnos)]

I have been using this computer only occasionally. It seems that with 5.4.0-65-generic and later I have had this problem more frequently, but I had this bug problem few times in May 2020, too (or at least I did not resume from suspend), but I had several successful resumes after that (according to journalctl). I wonder, if this could be related to graphics driver? I have been using nouveau instead of nvidia lately. nvidia-340 is no more developed IIRC.

[Guilherme G. Piccoli (gpiccoli)]

Unfortunately there is nothing relevant on logs in a first sight; your theory is interesting, is it possible for you to give a try to Nvidia drivers? At least as a data point.

You could try "ubuntu-drivers devices" to show the latest nvidia driver supported by your device, and use it for a while, trying to suspend and see if it fails or not. Please, let us know the results.
Cheers,

Guilherme

[Jarno Suni (jarnos)]

I switched to nvidia-340 driver (via "Additional Drivers"), rebooted and tested few times that suspend-resume works.

[Guilherme G. Piccoli (gpiccoli)]

Awesome, I'm glad that you nailed the issue. Guess using the nvidia driver is an option then, right?
Cheers!

[Jarno Suni (jarnos)]

Well after some kernel update it may be that Nvidia driver does not work anymore so I would have to use nouveau or another card..

[Guilherme G. Piccoli (gpiccoli)]

What is the output of "ubuntu-drivers devices" in your system?
As I mentioned to you, there are multiple nvidia drivers, like -340, -440, -460 ... you might have support for your card in a new version, which would be better than using an old version.