citricguy

Solved

Ubuntu 26.04 NVIDIA black screens after suspend: fbcon=nodefer workaround

Black screens after deep suspend on a Dell XPS 8940 with Ubuntu 26.04 and NVIDIA 595.99.02. The fbcon=nodefer workaround, matching logs, verification, and rollback.

UbuntuNvidiaSuspend ResumeFbconDell XPS 8940

Retro pixel art of Tux inserting a glowing fbcon=nodefer cartridge into a desktop tower, with one monitor asleep and the other waking up.

I was having a recurring problem where the desktop would go to sleep, but the screens would remain black when I tried to wake it with the keyboard or mouse. I ended up having to hold down the power button to turn the machine off and boot it again.

After checking the logs, the strongest lead was a hang during resume involving the NVIDIA display driver and the Linux framebuffer console (fbcon). Adding the kernel boot parameter fbcon=nodefer appears to have worked around it on this system. I’ve now had two successful suspend/resume cycles, including one overnight, but I’m continuing to watch it.

Short version

  • Symptom: the Dell XPS 8940 resumed from deep sleep, but the displays stayed black and the desktop was unusable.
  • Matching evidence: fbcon: Taking over console during resume, followed by blocked tasks in nvidia_modeset, fbcon_register_existing_fbs, and pm_restore_console.
  • Workaround used: append fbcon=nodefer through /etc/default/grub.d/99-codex-fbcon-nodefer.cfg, run sudo update-grub, then restart. The exact file contents and rollback are below.
  • Check: confirm the parameter in /proc/cmdline, then verify that suspend exits and the NVIDIA resume service completes.
  • Status as of November 1, 2026: two successful sleep/wake cycles, including overnight. This is an apparently successful workaround on this configuration.

The system

  • Computer: Dell XPS 8940, hardware version A00
  • Firmware/BIOS: Dell 2.27.1, dated April 3, 2025
  • OS: Ubuntu 26.04.1 LTS, x86-64
  • Kernel: 7.0.0-42-generic, Ubuntu package version 7.0.0-42.42
  • Desktop: GNOME Shell 50.1-0ubuntu1.4, Wayland session
  • systemd: 259.9-0ubuntu0.1
  • NVIDIA GPU: GeForce RTX 3060 Ti
  • NVIDIA driver: 595.99.02
  • NVIDIA package: nvidia-driver-595-open version 595.99.02-0ubuntu0.26.04.1
  • Integrated graphics: Intel UHD Graphics 750, using the i915 driver; the displays were connected to the NVIDIA card.
  • Sleep mode: deep, meaning suspend-to-RAM / ACPI S3. The machine also lists s2idle as available.
  • Automatic suspend: enabled after two hours of inactivity.

The NVIDIA suspend, resume, and hibernate services were already enabled. The NVIDIA driver was configured with PreserveVideoMemoryAllocations: 1 and TemporaryFilePath: "/var".

Symptoms and first checks

When I returned after the PC had been idle, the screens were black. Keyboard and mouse input didn’t bring the desktop back, and I had been holding the power button to force a restart.

The earlier logs showed the system starting deep suspend, followed by a new boot later, without a completed resume recorded in between. At that point, it wasn’t clear whether the PC was failing to wake at all, or waking and getting stuck before the display returned.

One initial lead was USB wake-up:

  • The keyboard was already enabled as a wake device.
  • The mouse was disabled as a wake device.
  • Both were connected through two USB hubs whose wake settings were disabled.
  • Wake-up was temporarily enabled for the mouse, hubs, and USB root hub.

The next sleep attempt still resulted in a black screen and an unusable desktop. Those temporary USB changes also reset after a restart. The keyboard subsequently woke the machine successfully with its original wake setting, so the USB changes do not appear to be the fix in this case.

Automatic suspend was also briefly turned off as a diagnostic workaround, then restored to its original two-hour setting. I wanted to keep suspend working for power saving.

What the failed-resume logs showed

A later failure produced more useful kernel logs. On October 31, the machine entered deep suspend, and the low-level ACPI resume completed:

PM: suspend entry (deep)
ACPI: PM: Low-level resume complete
ACPI: PM: Waking up from system sleep state S3
fbcon: Taking over console

Afterward, the kernel reported blocked tasks involving the NVIDIA modesetting driver, a framebuffer-console worker, and the system sleep process. Selected lines:

INFO: task nvidia-modeset/... blocked for more than 122 seconds.


Workqueue: events fbcon_register_existing_fbs
nvkms_ioctl_from_kapi ... [nvidia_modeset]


INFO: task systemd-sleep ... blocked for more than 122 seconds.
pm_restore_console ...


INFO: task systemd-sleep ... blocked on a semaphore likely last held by task kworker/...

The full traces indicated that the framebuffer-console worker was waiting inside NVIDIA modesetting code, while systemd-sleep was waiting for the console lock. That is a much closer match to a console/display-driver resume hang than a simple keyboard wake configuration problem.

The same resume also logged an ACPI firmware error:

ACPI BIOS Error (bug): Could not resolve symbol [\_SB.ITBP], AE_NOT_FOUND
ACPI Error: Aborting method \RWAK due to previous error (AE_NOT_FOUND)
ACPI Error: Aborting method \_WAK due to previous error (AE_NOT_FOUND)

I’m including it for completeness. I don’t know whether that firmware error contributed to the problem; the blocked-task traces were the more direct evidence for the workaround I tried.

Workaround: fbcon=nodefer

The workaround was to add this kernel boot parameter:

fbcon=nodefer

The Linux kernel documentation says this makes the framebuffer console bind immediately, rather than deferring its takeover. The idea here is to get that console initialization out of the way during startup, instead of having it occur during the suspend/resume sequence where the hang was observed.

An Ubuntu bug discussion describes a similar NVIDIA/fbcon deadlock and reports fbcon=nodefer as a workaround. The logs have a closely matching blocked-task pattern, although that does not establish that every underlying cause is identical.

How it was configured on the machine

Instead of editing the main /etc/default/grub file, a dedicated GRUB configuration file was added at:

/etc/default/grub.d/99-codex-fbcon-nodefer.cfg

Its contents are:

Terminal window
# Initialize the framebuffer console at boot to avoid a resume deadlock.
GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_DEFAULT} fbcon=nodefer"

Then the GRUB configuration was regenerated:

Terminal window
sudo update-grub

After restarting, I checked that the running kernel had received the parameter:

Terminal window
cat /proc/cmdline

The output included:

quiet splash fbcon=nodefer

For anyone trying this: preserve your existing GRUB options and use the procedure appropriate to your distribution and bootloader. The file above is what was used on this Ubuntu/GRUB installation; don’t replace an existing configuration file without checking its contents. Changing boot options can affect startup behavior, so make sure you know how to undo the change.

To remove this particular dedicated file on this installation, the reversal would be:

Terminal window
sudo rm /etc/default/grub.d/99-codex-fbcon-nodefer.cfg
sudo update-grub

A restart would then be needed. That removal command applies only if this is the dedicated file containing the workaround.

Results so far

After restarting with fbcon=nodefer, the logs showed the NVIDIA framebuffer console being initialized at boot:

fbcon: nvidia-drmdrmfb (fb0) is primary device

Two subsequent suspend/resume cycles completed:

  1. A short cycle on October 31 around 11:37 p.m.
  2. An overnight cycle beginning around 11:58 p.m. and ending around 8:56 a.m. on November 1.

For both cycles, the logs recorded PM: suspend exit, completion of systemd-suspend.service, and completion of nvidia-resume.service. After the overnight sleep, tapping the keyboard brought the machine back.

So far, this is an apparently successful workaround, not proof of a permanent upstream fix. The issue may depend on timing and could be intermittent. I’ll keep testing normal sleep and wake behavior.

If the problem comes back

First check cat /proc/cmdline. If fbcon=nodefer is missing, inspect the dedicated GRUB file shown above and confirm that its contents are still present. After restoring a missing configuration on this Ubuntu/GRUB installation, run sudo update-grub, restart, and check /proc/cmdline again.

If the parameter is already present, compare the current kernel and NVIDIA driver versions with the versions recorded here, and inspect the failed boot for the same blocked-task pattern using the commands below. A black screen by itself does not establish that this is the same hang.

Useful diagnostic commands

Check the running kernel and boot parameters:

Terminal window
uname -r
cat /proc/cmdline

Check available and selected suspend modes. The mode in square brackets is selected:

Terminal window
cat /sys/power/mem_sleep

Check NVIDIA driver and GPU details:

Terminal window
nvidia-smi

Check the current boot’s sleep and NVIDIA resume services:

Terminal window
journalctl -b -u systemd-suspend.service \
  -u nvidia-suspend.service \
  -u nvidia-resume.service

After a forced restart, inspect the previous boot’s kernel log:

Terminal window
journalctl -b -1 -k

Search that log for relevant suspend, console, and blocked-task messages:

Terminal window
journalctl -b -1 -k | grep -Ei \
  'suspend|resume|fbcon|nvidia|blocked for more|pm_restore_console'

If a system stays black after a failed wake and can safely be left alone briefly, the kernel’s blocked-task messages may take a couple of minutes to appear. In this case they were what made the problem much easier to diagnose.