How to put your baby, sorry, your Linux box to sleeperic

The Problem: A Restless Linux Box

Have you ever tried to put your Linux machine to sleep, only to watch it wake up immediately like an overtired toddler fighting bedtime? That's exactly what happened on my Ubuntu 24.04 system running kernel 6.14.0-35. The moment I initiated suspend, the system would wake up within 2-3 seconds. Every. Single. Time.

In the old days, this kind of problem would send you down a rabbit hole of forum posts, kernel logs, and trial-and-error fixes that could consume hours or even days. But thanks to AI assistance (specifically Claude Code), what could have been a frustrating ordeal became a systematic, almost enjoyable debugging session.

Initial Investigation: Checking the Usual Suspects

The first step in any suspend issue is understanding what's actually happening. We started by checking the system's suspend service status and logs:

Copy systemctl status systemd-suspend.service
journalctl -u systemd-suspend.service -n 50

The logs revealed an interesting pattern: the system was suspending successfully, but returning from sleep operation within seconds. The suspend service itself was working, but something was immediately waking the system.

The Wake Source Hunt

Linux systems have multiple potential wake sources configured in /proc/acpi/wakeup. Let's see what was enabled:

Copy cat /proc/acpi/wakeup

Several devices showed as *enabled:

• XHCI (USB controller) - pci:0000:00:14.0
• TXHC (Thunderbolt USB controller) - pci:0000:00:0d.0
• PEG0 (PCIe Graphics Port)
• RP08 (PCIe Root Port)
• AWAC (ACPI Wake Alarm Clock)

The USB controllers seemed like obvious culprits, right? Let's investigate further.

Red Herring #1: The Keyboard

My Lenovo keyboard had wakeup enabled:

Copy cat /sys/bus/usb/devices/3-7.1.1.4/power/wakeup
# Output: enabled

Natural assumption: the keyboard must be triggering spurious wake events. Let's disable it:

Copy sudo bash -c 'echo disabled > /sys/bus/usb/devices/3-7.1.1.4/power/wakeup'

Test suspend... still wakes immediately. Not the keyboard.

Red Herring #2: The USB Controllers

Maybe it's the USB controllers themselves? Let's disable them:

Copy sudo bash -c 'echo XHCI > /proc/acpi/wakeup'  # Disable main USB controller
sudo bash -c 'echo TXHC > /proc/acpi/wakeup'  # Disable Thunderbolt USB controller

Test suspend... still wakes immediately. What?!

The Wakeup Sources Investigation

A deeper look at /sys/kernel/debug/wakeup_sources revealed something interesting:

Copy sudo cat /sys/kernel/debug/wakeup_sources | head -30

The data showed:

• Keyboard (3-7.1.1.4): 0 wakeup events - completely innocent!
• USB controller (0000:00:14.0): 76 wake events
• Thunderbolt (0000:00:0d.0): 76 wake events
• device:63: 76 events

So the keyboard wasn't causing any wakes at all, despite being enabled. The USB controllers were active, but disabling them didn't help. What was going on?

The Deep Sleep Detour

At this point, we noticed the system was using s2idle (suspend-to-idle) rather than deep sleep:

Copy cat /sys/power/mem_sleep
# Output: [s2idle] deep

The brackets indicate s2idle was active. S2idle is a lighter sleep mode where the system stays in a low-power idle state rather than truly suspending. It's more susceptible to spurious wakeups.

My system supported deep sleep (S3), so let's try that:

Copy sudo bash -c 'echo deep > /sys/power/mem_sleep'

Test suspend... Success! The system went into deep sleep properly!

...but then it wouldn't wake up. Not with keyboard, not with mouse, not even with the power button. The system was completely unresponsive. Hard reset required.

Lesson learned: My system has broken S3 resume support. This is actually common on modern systems, especially laptops with newer Intel chipsets. Manufacturers often don't properly implement or test S3 suspend/resume, focusing instead on "Modern Standby" (s2idle).

Back to square one with s2idle.

Finding the Real Culprit: Detective Work

With USB controllers ruled out and deep sleep off the table, we needed to look at the other enabled wake sources. Let's check what PCIe devices were behind those enabled ports:

Copy lspci -s 00:1c.0  # Check RP08
# Output: 00:1c.0 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root Port

lspci -s 02:00.0  # Check what's behind it
# Output: 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411

Bingo! A Realtek Ethernet controller was sitting behind the RP08 wake source. Realtek NICs are notorious in Linux circles for causing spurious wakeup events, especially in s2idle mode.

The fix:

Copy sudo bash -c 'echo RP08 > /proc/acpi/wakeup'

This toggles RP08 from enabled to disabled. Test suspend...

It worked! The system now suspends properly and stays suspended until I wake it with the keyboard.

Understanding the Root Cause

Why does the Realtek Ethernet controller cause this issue?

1. s2idle behavior: In s2idle mode, the system doesn't fully power down. It keeps more devices active in low-power states.

2. Network polling: The Realtek driver may continue some level of network activity or polling that generates wake events.

3. Firmware quirks: Some Realtek NICs have firmware that doesn't properly handle s2idle states, generating spurious PME (Power Management Event) signals.

4. PCIe power management: The interaction between PCIe power management and the network controller's power states can cause issues.

Even though we disabled Wake-on-LAN at the network interface level, the PCIe-level wake source (RP08) was still enabled and responding to these spurious events.

How AI Revolutionized This Process

Let me be honest: this entire troubleshooting session, from problem statement to solution, took about 30 minutes. In the "old days" (yes, I'm that old), this kind of issue could easily consume an entire evening or weekend:

1. Searching forums: Hours spent reading threads where people describe similar-but-not-quite-the-same issues
2. Trial and error: Random suggestions to try without understanding why
3. Dead ends: Following promising leads that turn out irrelevant to your specific hardware
4. Documentation diving: Parsing through kernel documentation to understand power management subsystems
5. Frustration: Giving up and just living with the problem

With AI assistance (Claude Code in this case), the process was:

1. Systematic investigation: Each step built logically on the previous findings
2. Parallel exploration: Checking multiple potential causes simultaneously
3. Context awareness: Understanding the relationships between different system components
4. Hypothesis testing: Methodically ruling out suspects with clear tests
5. Knowledge synthesis: Combining information from logs, sysfs, and system state

The AI didn't just tell me "disable RP08" - it guided me through the investigation, explained what each command revealed, and helped build a mental model of how Linux power management works.

The Solution: Step-by-Step

Here's the final solution for anyone with similar issues:

1. Identify your sleep mode

Copy cat /sys/power/mem_sleep

If you see [s2idle], you're in the light sleep mode susceptible to spurious wakeups.

2. Check wake sources

Copy cat /proc/acpi/wakeup | grep enabled

3. Investigate enabled PCIe wake sources

Copy # For each enabled PCIe port, check what device is behind it
lspci -s <address>

4. Look for Realtek Ethernet controllers

Copy lspci | grep -i ethernet

5. If you find a Realtek NIC, check its wake source

Look in /proc/acpi/wakeup for the PCIe root port (RPxx) corresponding to the NIC's address.

6. Disable the problematic wake source

Copy sudo bash -c 'echo RP08 > /proc/acpi/wakeup'

(Replace RP08 with whatever your PCIe root port is called)

7. Make it permanent

The above change won't survive a reboot. To make it permanent, create a systemd service:

Copy sudo nano /etc/systemd/system/disable-rp08-wake.service

Copy [Unit]
Description=Disable RP08 wake source
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo RP08 > /proc/acpi/wakeup'

[Install]
WantedBy=multi-user.target

Enable it:

Copy sudo systemctl enable disable-rp08-wake.service

Alternative Solutions

If disabling the PCIe wake source doesn't work for you, or you need the network controller to be able to wake the system, here are alternatives:

Try updating the NIC driver

Copy sudo ethtool -s enp2s0 wol d  # Disable Wake-on-LAN explicitly

Check BIOS settings

Some BIOS/UEFI settings affect suspend behavior:

• Look for "Modern Standby" vs "S3" options
• Check "Wake on LAN" settings
• Review "USB wake" settings

Kernel parameters

Try adding to your kernel command line (in GRUB):

Copy mem_sleep_default=s2idle

Last resort: blacklist the driver

If nothing else works and you don't need the onboard Ethernet:

Copy echo "blacklist r8169" | sudo tee -a /etc/modprobe.d/blacklist.conf

Conclusion

Linux power management can be tricky, with multiple layers (ACPI, PCIe, USB, driver-level) all interacting. What appears as a simple "suspend doesn't work" issue often has a complex root cause requiring systematic investigation.

The key lessons:

1. Spurious wakeups aren't always from USB devices - Check PCIe wake sources too
2. Realtek NICs are common culprits - Especially in s2idle mode
3. S3 deep sleep isn't always supported - Modern systems may have broken S3 resume
4. Disable at the right level - Individual USB device settings won't help if the controller or PCIe port is the issue
5. AI assistance makes debugging systematic - What used to take hours can now take minutes

And remember: sometimes the culprit isn't the keyboard you suspected all along, but the innocent-looking network card quietly sending spurious wake signals in the background.

Sleep tight, Linux boxes!

Have you encountered suspend issues on Linux? What was your culprit? Share your experiences in the comments below!