Machine never recovers from suspend

Ask Fedora
,
1

I’m running Fedora 34 (recently upgraded from 32) with Cinnamon as a desktop, on a Dell XPS 15 9550, using NVIDIA drivers, and booting from an external SSD attached via USB-C. Software and firmware are fully up-to-date.

Mostly, things work fine. But although i can suspend the machine, it never successfully resumes from suspension. This was true on 32 as well. I also boot this machine into Ubuntu 18.04, and there, suspend and resume works fine.

I commented about this on an earlier thread, but i thought i would post more details, since it’s still happening.

I did a little test just now, which went as follows:

  • 19:20 boot, then log in
  • 19:23 suspend
  • 19:25 try to resume by pressing the power button
  • 19:26 decide that the resumption has failed, and turn off by holding down the power button
  • 19:27 boot, then log in
  • 19:29 shut down

After that, i booted up again to make this post. At this point, in terms of journalctl boot offset, the 19:20 boot is at offset -2, and 19:27 is at offset -1.

When suspending, the window manager shut down, leaving a console message on the screen, before powering down:

[  160.027319] __common_interrupt: 5.33 No irq handler for vector

When resuming, the machine got as far as a console showing two messages:

[  160.027319] __common_interrupt: 5.33 No irq handler for vector
[  172.592381] __common_interrupt: 5.33 No irq handler for vector

I have no idea if this is significant. I can see that these messages were printed during the 19:20 boot, and not 19:27 or the current one:

$ journalctl -o short-monotonic -b -2 | fgrep '__common_interrupt: 5.33 No irq handler for vector'
[  160.027319] rife kernel: __common_interrupt: 5.33 No irq handler for vector
[  172.592381] rife kernel: __common_interrupt: 5.33 No irq handler for vector
$ journalctl -o short-monotonic -b -1 | fgrep '__common_interrupt: 5.33 No irq handler for vector'
$ journalctl -o short-monotonic -b 0 | fgrep '__common_interrupt: 5.33 No irq handler for vector'
$

I have posted the output of journalctl -o short-iso-precise -b $offset for both boots, and of sudo lshw as a gist.

After booting, and before suspending, i made a manual entry into the system log using the logger utility; each of the messages is prefixed with “hear ye”, to make it easy to recognise.

It’s clear from the log that the machine is starting to resume, and making a lot of progress. Seconds after i try to resume, the log says:

2021-06-26T19:25:07.619726+0100 rife systemd-sleep[4041]: System resumed.

And then there’s lots of other stuff, mostly to do with the network. But i never see my desktop again.

Does anyone have any idea what the problem might be? Or, more likely, does anyone have any idea how i could investigate further?

EDIT: I wondered if i just wasn’t waiting long enough for the resume to complete, so after making this post, i tried a suspend and resume, and then went off to fix my roof. The machine made no more progress than in the test above.

2

Hello,
I have been working with suspend - resume issues too. The more I research the more confused I get. I have two machines, an older intel i5 Lenovo and a new amd Lenovo. I choose to operate with BIOS option “secure boot - enabled” and hence by default F34 installation, the hibernate mode (is that ACPI Suspend mode = S4 or is it S5??) called suspend-to-disk is blocked from functioning by default. I also encrypt my swap partition and encrypt the btrfs “/” mount point partitions. I have not attempted to activate the suspend-to-disk function with secure boot enabled.

On both machines I have GNOME default desktop (so Wayland mode) and KDE Plasma desktop installed, which I always invoke with the X-Org option.

On the older intel machine, selecting “suspend” with the mouse from both desktop environments and invoking the desktop command shell instruction to suspend all result in same action, after a few seconds the screen goes black the system reduces power and the power led starts a slow flashing. Any timespan later, if the battery has not discharged first, I touch any key on the keyboard and the system restarts to a lockscreen asking for my password. Touchpad is not responsive until after it wakes up, and a message shows up saying “Touchpad Activated” during the wakeup procedure. I have not used a wired mouse or bluetooth mouse.
I dual boot with Windows 10 Home on the intel machine and no issues happen when starting up Windows from Grub Menu.

For the new AMD machine configuration is slightly different: No swap partition is present. btrfs “/” partition is encrypted, secure boot enabled. Because of this I don’t expect suspend-to-disk to work at all, no swap partition exists I THINK that partition is where the disk image is placed.

In KDE Plasma X-Org mode, if I select the mouse option “suspend” from settings power management screen, the system after a few seconds presents a dark screen, and the led on the power button remains constantly illuminated. For a “short” time of several minutes, if I touch the space bar the “lockscreen” login screen raises and I can enter password and re-enter the desktop. But after longer delay, and when the mouse is used under GNOME-Wayland and when suspend is invoked from a shell command line, the system screen goes dark, and the led on the power button remains constantly on. The only way to resume is to press the power button until the led goes dark. Then pressing it again invokes a system reboot, requiring entry of the luks passcode in the procedure and then username passphrase on the desktop entry page. Also intermittently windows 10 Pro I have for dual boot will request bitlocker passkey before booting into Windows 10 Pro desktop.

In researching I have become confused with a variety of nomenclature:
ACPI states are enumerated as S0, S1, S2, S3 and for hibernate to disk S4.
kernel.org and fedora don’t use this nomenclature, using tems ‘idle’ ‘deep’ ‘freeze’ and a couple of others, some mentioned in kernel.org and not mention in fedora and vice versa.
AMD and Microsoft are collaborating, (or is it colluding or conspiring?) with a new suspend status they call S0ix.

Fedora has provided some configuration files sleep.conf and resume.conf ?? how should these be edited to allow suspend to ram with minimal power consumption? (so S3 state, is that “deep” sleep?)

3

It is happening with me too
Has you issue been resolved?
If yes will you help me?

4

I have not been able to resolve this problem.

5

I experience the same problem since yesterday on my Asus Zenbook Pro 15 UX550V. If the notebook suspense after some time it doesn’t recover but it’s still running.

Is this the reason?

Okay, this was my solution:

cat > /etc/modprobe.d/nvidia-pwmgt.conf << EOF
# Enable VRAM Allocation preservation for system suspension
options nvidia NVreg_PreserveVideoMemoryAllocations=1
EOF

systemctl enable nvidia-suspend.service nvidia-hibernate.service nvidia-resume.service
systemctl is-enabled nvidia-suspend nvidia-hibernate nvidia-resume
systemctl reboot

Source: Resuming from suspend issue (driver 450.57, Fedora 32, modesetting enabled, GTX 750 Ti) - #6 by andre.ocosta - Linux - NVIDIA Developer Forums

1 Like
6

It says:
Failed to enable unit: Unit file nvidia-suspend.service does not exist.
Can you help me on how to solve this error?

7

unfortunately not, it worked for me

8

Thank you hero. I’ve been dealing with this problem for a week, and your resolution worked.

9

I feel a little proud as a noob :smiling_face_with_three_hearts:

1 Like
10

You can figure how to define and activate those services directly from nvidia’s power management info.

11

I finally got round to trying this (on F36), and i still can’t suspend and resume. However, it looks to me more like the machine is never suspending - the power light on the keyboard never goes out.

Hibernation and reawakening does work, though. I don’t think i tested that before, so i have no idea if that’s new!