Nvidia driver 550.76-1 fails suspending; results in black screen unresponsiveness

thomas.gfeller · April 27, 2024, 8:16am

Hi everyone.

I recently upgraded my Nvidia driver to 550.76-1, and everything seems to be working properly except for the sleep mode. When I try to put my notebook into sleep mode, either by closing the lid or triggering it from the menu, the system does not initiate sleep mode correctly. Instead, it remains with an active black screen and becomes completely unresponsive. The only way to resolve the issue is by forcing a reboot with the power button.

             .',;::::;,'.                qdrop@qdrop-fedora-pro9i 
         .';:cccccccccccc:;,.            ------------------------ 
      .;cccccccccccccccccccccc;.         OS: Fedora Linux 39 (Workstation Edition) x86_64 
    .:cccccccccccccccccccccccccc:.       Host: 83BU Yoga Pro 9 14IRP8 
  .;ccccccccccccc;.:dddl:.;ccccccc;.     Kernel: 6.8.7-200.fc39.x86_64 
 .:ccccccccccccc;OWMKOOXMWd;ccccccc:.    Uptime: 12 mins 
.:ccccccccccccc;KMMc;cc;xMMc:ccccccc:.   Packages: 2373 (rpm), 47 (flatpak) 
,cccccccccccccc;MMM.;cc;;WW::cccccccc,   Shell: bash 5.2.26 
:cccccccccccccc;MMM.;cccccccccccccccc:   Resolution: 3440x1440 
:ccccccc;oxOOOo;MMM0OOk.;cccccccccccc:   DE: GNOME 45.5 
cccccc:0MMKxdd:;MMMkddc.;cccccccccccc;   WM: Mutter 
ccccc:XM0';cccc;MMM.;cccccccccccccccc'   WM Theme: Adwaita 
ccccc;MMo;ccccc;MMW.;ccccccccccccccc;    Theme: Adwaita [GTK2/3] 
ccccc;0MNc.ccc.xMMd:ccccccccccccccc;     Icons: Adwaita [GTK2/3] 
cccccc;dNMWXXXWM0::cccccccccccccc:,      Terminal: gnome-terminal 
cccccccc;.:odl:.;cccccccccccccc:,.       CPU: 13th Gen Intel i9-13905H (20) @ 5.200GHz 
:cccccccccccccccccccccccccccc:'.         GPU: NVIDIA GeForce RTX 4060 Max-Q / Mobile 
.:cccccccccccccccccccccc:;,..            GPU: Intel Raptor Lake-P [Iris Xe Graphics] 
  '::cccccccccccccc::;,.                 Memory: 4150MiB / 31827MiB

I’ve been investigating the issue and found some relevant logs in journalctl:

journalctl -u systemd-suspend
-- Boot 0df60399591a4e408c1e4767eb9e2b56 --
Apr 26 11:46:41 qdrop-fedora-pro9i systemd[1]: Starting systemd-suspend.service - System Suspend...
Apr 26 11:46:41 qdrop-fedora-pro9i systemd-sleep[9565]: Performing sleep operation 'suspend'...
Apr 26 12:28:24 qdrop-fedora-pro9i systemd-sleep[9565]: System returned from sleep operation 'suspend'.
Apr 26 12:28:25 qdrop-fedora-pro9i systemd[1]: systemd-suspend.service: Deactivated successfully.
Apr 26 12:28:25 qdrop-fedora-pro9i systemd[1]: Finished systemd-suspend.service - System Suspend.
Apr 26 12:28:25 qdrop-fedora-pro9i systemd[1]: systemd-suspend.service: Consumed 4.688s CPU time.
Apr 26 12:30:56 qdrop-fedora-pro9i systemd[1]: Starting systemd-suspend.service - System Suspend...
Apr 26 12:30:56 qdrop-fedora-pro9i systemd-sleep[10542]: Performing sleep operation 'suspend'...

This log shows that the system is attempting to suspend, but it seems to be failing and returning from the suspend operation without successfully entering sleep mode.

Additionally, I found some concerning errors related to the NVIDIA driver:

Apr 26 11:02:10 qdrop-fedora-pro9i kernel: ------------[ cut here ]------------
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: WARNING: CPU: 6 PID: 12727 at /tmp/akmodsbuild.c53mNnFM/BUILD/nvidia-kmod-550.76/_kmod_build_6.8.7-300.fc40.x86_64/nvidia/nv.c:4580 nv_set_system_power_state>
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: Modules linked in: xt_mark wireguard curve25519_x86_64 libcurve25519_generic ip6_udp_tunnel udp_tunnel uinput snd_seq_dummy snd_hrtimer rfcomm xt_conntrack x>
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  x86_pkg_temp_thermal intel_powerclamp coretemp snd_sof_utils snd_soc_hdac_hda kvm_intel snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi soundwire_gen>
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  industrialio_triggered_buffer ideapad_laptop processor_thermal_wt_req snd mei_me kfifo_buf i2c_i801 intel_pmc_core platform_profile processor_thermal_power_>
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ip_tables i2c_dev fuse
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: CPU: 6 PID: 12727 Comm: nvidia-sleep.sh Tainted: P           OE      6.8.7-300.fc40.x86_64 #1
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: Hardware name: LENOVO 83BU/LNVNB161216, BIOS MBCN29WW 11/17/2023
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RIP: 0010:nv_set_system_power_state+0x40d/0x470 [nvidia]
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: Code: 0f eb 40 4d 8b a4 24 70 06 00 00 4d 85 e4 74 33 49 8b bc 24 d0 02 00 00 ba 01 00 00 00 89 de e8 19 c9 ff ff 89 c5 85 c0 74 d9 <0f> 0b 48 c7 c7 40 03 da>
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RSP: 0018:ffff9aca8d487ae0 EFLAGS: 00010206
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RAX: 000000000000ffff RBX: 0000000000000001 RCX: 0000000080020000
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RDX: ffff8dc4c4efb650 RSI: 0000000000000286 RDI: ffff8dc4c4efb648
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RBP: 000000000000ffff R08: ffff8dc529443000 R09: 0000000080020000
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: R10: 0000000080020000 R11: 0000000000000000 R12: ffff8dc4c4efb000
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: R13: ffff8dc4c4efb648 R14: ffff8dc529443000 R15: ffff8dc529443000
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: FS:  00007fb1fa1cb740(0000) GS:ffff8dcc0f780000(0000) knlGS:0000000000000000
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: CR2: 000001540057e000 CR3: 00000001f7a2a000 CR4: 0000000000f50ef0
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: PKRU: 55555554
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: Call Trace:
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  <TASK>
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? nv_set_system_power_state+0x40d/0x470 [nvidia]
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? __warn+0x81/0x130
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? nv_set_system_power_state+0x40d/0x470 [nvidia]
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? report_bug+0x16f/0x1a0
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? handle_bug+0x3c/0x80
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? exc_invalid_op+0x17/0x70
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? asm_exc_invalid_op+0x1a/0x20
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? nv_set_system_power_state+0x40d/0x470 [nvidia]
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  nv_procfs_write_suspend+0xe1/0x160 [nvidia]
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  proc_reg_write+0x5a/0xa0
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  vfs_write+0xed/0x470
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? do_syscall_64+0x8f/0x170
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ksys_write+0x6d/0xf0
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  do_syscall_64+0x83/0x170
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? filp_flush+0x52/0x70
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? syscall_exit_to_user_mode+0x83/0x230
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? do_syscall_64+0x8f/0x170
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? syscall_exit_to_user_mode+0x83/0x230
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? do_syscall_64+0x8f/0x170
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? syscall_exit_to_user_mode+0x83/0x230
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? do_syscall_64+0x8f/0x170
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? remove_wait_queue+0x24/0x60
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? do_wait+0xa1/0x100
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? ptep_set_access_flags+0x32/0x40
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? wp_page_reuse+0x8e/0xa0
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? do_wp_page+0xdf/0xbc0
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? do_fcntl+0x3be/0x6a0
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? __pfx_child_wait_callback+0x10/0x10
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? __pte_offset_map+0x1b/0x180
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? __handle_mm_fault+0xb2b/0xe80
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? __count_memcg_events+0x4d/0xc0
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? count_memcg_events.constprop.0+0x1a/0x30
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? handle_mm_fault+0x1f2/0x350
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? do_user_addr_fault+0x304/0x670
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  ? exc_page_fault+0x7f/0x180
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  entry_SYSCALL_64_after_hwframe+0x78/0x80
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RIP: 0033:0x7fb1fa2d9834
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d 15 f8 0d 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54>
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RSP: 002b:00007ffc59f4eb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fb1fa2d9834
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RDX: 0000000000000008 RSI: 0000564e06db91a0 RDI: 0000000000000001
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: RBP: 00007ffc59f4eb60 R08: 0000000000000410 R09: 0000000000000001
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: R10: 0000000000000004 R11: 0000000000000202 R12: 0000000000000008
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: R13: 0000564e06db91a0 R14: 00007fb1fa3b25c0 R15: 00007fb1fa3aff00
Apr 26 11:02:10 qdrop-fedora-pro9i kernel:  </TASK>
Apr 26 11:02:10 qdrop-fedora-pro9i kernel: ---[ end trace 0000000000000000 ]---
Apr 26 11:02:10 qdrop-fedora-pro9i nvidia-sleep.sh[12727]: /usr/bin/nvidia-sleep.sh: line 20: echo: write error: Input/output error
Apr 26 11:02:10 qdrop-fedora-pro9i systemd[1]: nvidia-suspend.service: Main process exited, code=exited, status=1/FAILURE
Apr 26 11:02:10 qdrop-fedora-pro9i systemd[1]: nvidia-suspend.service: Failed with result 'exit-code'.
Apr 26 11:02:10 qdrop-fedora-pro9i systemd[1]: Failed to start nvidia-suspend.service - NVIDIA system suspend actions.

What’s interesting is that the first suspend when booted freshly often works while the second fails almost always.

These errors suggest that there might be an issue with the NVIDIA driver and its interaction with the system’s suspend functionality.

The issue is not existing when disabling the NVIDIA GPU with envycontrol -s integrated or uninstalling the proprietary driver altogether. Nouveau does not exhibit this behaviour.

Any help would be greatly appreciated. I’m willing to support in debugging.

I also posted this issue here: Nvidia driver 550.76-1 fails suspending; results in black screen unresponsiveness - Fedora Discussion

balrog86 · April 27, 2024, 3:11pm

Hi, I had the same issues, too. Found an acpi _osi related fix for the “unresponsive” issue after sleep.
I think the issue could also be related to nvidia-closed and/or <550.78 related. See workaround/hints here

ps.: I’m new here, but I think they have a bug reporting upload template that would contain much more useful information on what’s going on on your system.

thomas.gfeller · April 28, 2024, 8:03am

Hi @balrog86, thank you very much for your valuable input!

The issue only surfaced with the 550.78 version; this fix seems to have been around for years already.

I tried it nonetheless, but unfortunately, it didn’t resolve the problem. Note that I added this string to the kernel parameters: acpi_osi=! "acpi_osi=Windows 2015" (which I got from strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort | tail -1). The parameter is set twice - was this correct? Looks a bit odd to me.

What’s more important is that the system freezes entirely, rendering it unresponsive to even ping requests.

I was unable to locate the mentioned template; could you kindly share a link to it?

balrog86 · April 28, 2024, 10:54am

It would be helpful to see the output of nvidia-bug-report.sh.

The kernel parameter(s) should look like [...] acpi_osi=! "acpi_osi=xxx". Here is more information
I once had a dGPU on a lenovo laptop that did suspend correctly only with a specific acpi_osi (not the most recent one). Blame the bios vendor and/or try older strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort -u entries.
Are you sure you tested the 550.78-open version? In your initial post you wrote 550.76-1.
Also on my current nvidia dGPU I don’t use nvidia-*.service(s), as I think they do mainly good work on primary gpu’s such as restoring video memory after suspend, please correct me if I’m wrong and feel free to test disabling/stoping them.
Also I currently experience a “freeze” issue after suspend, but I can’t reproduce this reliably yet.
It’s something like

systemctl syspend
close laptop lid
remove external dp monitor and/or power cable?
wait a long period of time?
open laptop lid
→ black screen, however SysRq+u “resolves” the issue, bringing me back to login.

I’ll do a bug report on this once I can reproduce it in case it’s a driver issue

thomas.gfeller · April 29, 2024, 5:47am

Apologies for the confusion in my previous post. The issues I mentioned were present with NVIDIA driver version 550.76. However, the subsequent version 550.78 resolved those issues, indicating that there was a temporary problem with the 550.76 driver.

I appreciate your valuable debugging suggestions. In the future, I will be sure to run the proposed debugging script to provide more detailed information.

Regarding your issue: I’ve encountered similar problems with my laptop as well. What resolved them for me was developing a habit of first unplugging my docking station while the laptop is still awake, and only then closing the lid. When connecting to another dock, I first wake the laptop and only then connect the dock. This approach has worked smoothly for me and is easy to follow.

Changing the hardware configuration significantly (e.g., docking stations) while the laptop is in sleep mode has led to issues in the past.

balrog86 · April 29, 2024, 9:32am

It’s very bad when one suspends a laptop without doing so, driving to a customer and end up on a frozen system by opening the lid/on resume.
I will try this, is could be an okay workaround., thank you.

thomas.gfeller · April 29, 2024, 11:16am

I share your opinion. However, to be frank, I encountered similar issues even with Windows. It might be a UEFI problem, which is unrelated to Linux, or some interdependencies between components.

You could try uninstalling the Nvidia drivers entirely and rely on the open-source Nouveau driver as a temporary solution. This approach might help isolate the root cause of the problem.

system · May 13, 2024, 11:16am

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.