{/* banner prompt: Excellent. Here is a creative and engaging prompt for a banner image, based on the provided blog post.

---

### Banner Image Prompt

**A cinematic digital art illustration of a sleek, modern Linux server in a dark, quiet room, symbolizing a system trying to sleep. A soft, pulsing blue crescent moon icon is faintly visible on the server's chassis, indicating its attempt to enter suspend mode. However, a single Ethernet port on the back glows with a disruptive, jagged, electric orange light. This light sends a 'wake-up' signal, visualized as a sharp, glitchy energy wave, preventing the system from resting.**

**Floating above the scene is a serene, abstract AI construct, represented by a glowing network of interconnected nodes and lines of light. The AI is analyzing the disruptive signal, with a focused beam of clean, white light pointing directly at the problematic Ethernet port, highlighting it as the culprit. In the background, faint, out-of-focus lines of code and system logs hint at the debugging process.**

**The overall mood is a contrast between the calm, deep blue tones of sleep and the sharp, aggressive orange of the wake-up signal, all being systematically resolved by the intelligent AI presence.**

**Style:** Technology-themed, highly detailed, dramatic lighting, cinematic, digital art.
**Aspect Ratio:** 16:9

Additional instructions: A Penguin holding a screw driver and spanner */}

## 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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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
```bash
cat /sys/power/mem_sleep
```

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

### 2. Check wake sources
```bash
cat /proc/acpi/wakeup | grep enabled
```

### 3. Investigate enabled PCIe wake sources
```bash
# For each enabled PCIe port, check what device is behind it
lspci -s <address>
```

### 4. Look for Realtek Ethernet controllers
```bash
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
```bash
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:

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

```ini
[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:
```bash
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
```bash
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):
```
mem_sleep_default=s2idle
```

### Last resort: blacklist the driver
If nothing else works and you don't need the onboard Ethernet:
```bash
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!*

fa825505d34ef4d9ede6f8e4147410aa326d916701be0fab0cfc88300b287a07

Debugging Linux suspend issues can be frustrating. This article chronicles the systematic troubleshooting of immediate wake-from-suspend problems, exploring USB controllers, sleep modes, and ultimately discovering a Realtek Ethernet controller as the culprit.

A deep dive into troubleshooting Linux suspend issues, from USB controllers to sleep modes, and how AI transformed a potentially frustrating debugging session into a systematic investigation.

Tag: Power-management

Tag: Power-management

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