You close the lid and the battery vanishes
You pack your laptop into your bag, open it three hours later, and find the battery completely drained. Or you wake the machine and the screen stays black while the cooling fans spin at maximum speed. Suspend and resume issues are among the most common complaints on Fedora laptops. The system attempts to save your session to RAM and power down the peripherals, but something interrupts the handshake between the kernel, the firmware, and the hardware drivers.
Run the diagnostic steps below in order. Start with a clean kernel update, check the journal for the exact failure point, and isolate the offending driver. A botched suspend cycle can corrupt open file handles or leave storage controllers in an inconsistent state. Test each change in a controlled window before trusting it with unsaved work.
What is actually happening
Linux suspend relies on the Advanced Configuration and Power Interface to tell the motherboard to cut power to non-essential components. The kernel saves the memory state of every loaded driver, writes the session context to RAM, and sends a sleep signal to the UEFI firmware. When you press the power button or open the lid, the firmware restores CPU power, the kernel reloads the driver states, and the desktop environment redraws the screen.
The process requires strict coordination. Every driver must release its hardware resources in the exact order the kernel expects. If a Wi-Fi card refuses to unload its firmware, or if a graphics driver leaves the display controller powered, the transition stalls. The result is a black screen, a hard reboot, or a battery that drains as fast as if the laptop were running normally. Think of it like parking a complex machine. Every gear must lock into place. If one gear keeps spinning, the whole mechanism jams and the safety system triggers a full shutdown.
Modern laptops also rely on the real-time clock and USB controllers to handle wake events. The kernel schedules a wake timer, and the firmware obeys it literally. When the firmware table contains a bug, or when a driver schedules a wake event it never cancels, the system wakes itself immediately after sleeping. The kernel logs every step of this sequence. Reading those logs tells you exactly which component broke the chain.
Check the journal before guessing which driver is at fault. Half the time the symptom is a firmware quirk, not a kernel bug.
The fix and how to apply it
Start with the baseline. Fedora ships with a rolling kernel update model, but your system might be running a version from several weeks ago. Driver fixes for sleep states land in kernel updates frequently. Run a full refresh and reboot.
sudo dnf upgrade --refresh # forces metadata sync and pulls the latest kernel and driver packages
sudo reboot # applies the new kernel and clears stale driver caches from the previous boot
Convention aside: dnf upgrade --refresh is the standard weekly maintenance command on Fedora. It forces the package manager to ignore cached repository state and fetch the latest available packages. Always run it before chasing hardware bugs.
If the update does not resolve the issue, check the system journal for the exact failure point. The kernel logs the suspend transition and any driver timeouts. Use the extended journal flags to get readable output.
journalctl -b -1 -p warning | grep -iE 'suspend|sleep|acpi|firmware' # shows warnings from the previous boot cycle
journalctl -xeu systemd-suspend.service # displays the full suspend unit log with explanatory context
Look for lines mentioning rtcwake, iwlwifi, amdgpu, nouveau, or xhci_hcd. These are the usual suspects. Wi-Fi cards often fail to reinitialize their firmware after sleep. Graphics drivers sometimes leave the display controller in a powered-off state. Real-time clock alarms can wake the system immediately after it tries to sleep.
Address the Wi-Fi driver first if you see firmware reload errors. Many Intel and Realtek cards need a manual firmware reset to recover cleanly.
sudo modprobe -r iwlwifi # unloads the Intel Wi-Fi driver to clear its internal state
sudo modprobe iwlwifi # reloads the driver with a fresh firmware handshake
nmcli radio wifi on # re-enables the network manager radio after the driver reload
If your laptop uses an AMD or NVIDIA GPU, the display manager might be holding the DRM context open. Close all applications that use hardware acceleration, then test the suspend cycle again. Proprietary GPU drivers often require a clean session state to hand off the display controller correctly.
When the system wakes instantly or drains battery, the RTC wake timer is usually the culprit. The kernel schedules a wake event, and the firmware obeys it literally. Check the current wake configuration.
cat /sys/power/wakeup_count # shows the current wake counter threshold the kernel expects
cat /proc/acpi/wakeup # lists which devices are allowed to trigger a wake event
Disable unnecessary wake sources. The touchpad, USB controllers, and sometimes the audio codec can trigger spurious wake events. Toggle the capability by echoing the device name.
echo XHCI | sudo tee /proc/acpi/wakeup # toggles the USB 3.0 controller wake capability
echo EHC1 | sudo tee /proc/acpi/wakeup # toggles the USB 2.0 controller wake capability
echo PS2K | sudo tee /proc/acpi/wakeup # toggles the legacy keyboard wake capability
Convention aside: Changes to /proc/acpi/wakeup only survive until the next reboot. To make them permanent, you need a systemd service or a udev rule. Do not edit /usr/lib/ files. Place custom scripts in /etc/ or use systemctl enable for persistent configuration. Manual file edits drift, snapshots stay.
Test the fix by forcing a controlled suspend cycle.
systemctl suspend # sends the ACPI sleep signal directly from the command line
Wait ten seconds, then press the power button. If the desktop returns and the network reconnects, the issue was a transient driver state or a stale wake timer.
Run the journal check after every test cycle. Read the actual error before guessing.
Verify it worked
Confirm the power state transition logged correctly. The kernel writes explicit markers when it enters and exits low-power states.
journalctl -b -1 | grep -i 'PM: suspend' # verifies the kernel completed the power management cycle
cat /sys/power/state # shows available sleep states for your hardware
If the journal shows PM: suspend entry followed by PM: suspend exit, the kernel handled the transition cleanly. Check your battery percentage before and after a ten-minute sleep window. A drop of less than two percent indicates the RAM retention circuit is working correctly.
Test network recovery by pinging an external host immediately after resume.
ping -c 3 1.1.1.1 # confirms the network stack reinitialized and obtained a route
nmcli device status # shows whether the Wi-Fi or Ethernet interface is connected
If the ping succeeds and the device status shows connected, the driver handshake completed successfully. Reboot once more to ensure the new state persists across a full cold boot.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
Forcing a suspend cycle while a disk I/O operation is pending will cause the kernel to hang. You will see PM: Device 0000:00:14.0 failed to suspend async in the journal. Close any file managers, backup tools, or database services before testing. The kernel cannot safely power down storage controllers while write buffers are flushing.
Another common trap is Secure Boot interfering with unsigned third-party drivers. If you see modprobe: ERROR: could not insert 'nvidia': Operation not permitted, the kernel is blocking the driver from loading during resume. Disable Secure Boot in the firmware setup, or enroll the MOK for the proprietary driver. Never disable Secure Boot just to fix sleep. Fix the driver signature first.
Some laptops ship with aggressive power-saving firmware that cuts power to PCIe slots too early. The kernel will log pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer. Add the kernel parameter pcie_aspm=off to the boot loader to disable active state power management for PCIe devices. Edit /etc/default/grub, append the parameter to GRUB_CMDLINE_LINUX, and run sudo grub2-mkconfig -o /boot/grub2/grub.cfg. Reboot to apply.
Convention aside: SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A policy denial during suspend usually means a service is trying to access a hardware node it was not granted permission for. Fix the policy or the service configuration instead of switching to permissive mode.
Run journalctl first. Read the actual error before guessing.
When to use this vs alternatives
Use a kernel update when the issue appeared after a major Fedora release or when a new hardware revision shipped. Use firmware updates when the motherboard vendor released a BIOS or UEFI patch for ACPI tables or battery management. Use kernel parameters like acpi_osi=! or pcie_aspm=off when the hardware has a known firmware bug that the kernel cannot work around automatically. Use hibernate when you need to preserve the session across a complete power loss and your swap partition is larger than your RAM. Stay on the default suspend cycle if you only need quick resume and your battery health is stable.
Snapshot the system before the upgrade. Future-you will thank you.