How to Troubleshoot Suspend Failures on the Lenovo Yoga 9i Aura with Linux

Some Linux laptops can appear to suspend successfully and then immediately wake back up, or return to the login screen without any user input. One possible explanation is an erroneous wake event from a hardware device.

This guide focuses on the Lenovo Yoga 9i 2-in-1 Aura Edition, but the same troubleshooting approach can apply to other laptops using Intel Core Ultra 200V-series processors, including systems built around the Core Ultra 7 258V. The exact devices and paths vary by hardware, firmware, and kernel.

The important point is that the wake event can come from various hardware sources. An ELAN touchpad is one example. The Intel Integrated Sensor Hub (ISH) is another. USB devices, I2C devices, GPIOs, ACPI devices, and other platform components can also be involved. The purpose of this procedure is to determine which wake source is responsible on the affected system.

What the problem looks like

A typical failure looks like this:

Request suspend
      ↓
Linux enters suspend
      ↓
Erroneous hardware wake event
      ↓
Laptop immediately resumes
      ↓
Login screen appears again

The wake event may occur without touching the keyboard, mouse, touchpad, lid, or power button. If that happens, a hardware-generated wake event is one possible cause worth investigating.

First test: confirm the suspend behavior

Try suspending normally from your desktop environment. You can also test directly with systemd:

systemctl suspend

After invoking suspend, wait several seconds without touching the laptop.

If the machine stays asleep, the problem may not be an immediate hardware wake event. If it immediately wakes and returns to the login screen without input, continue with wake-source investigation.

Check the kernel wakeup sources

Linux exposes wakeup-source information through debugfs. Run:

sudo cat /sys/kernel/debug/wakeup_sources

The most useful thing to look at initially is the event count for each wakeup source. The device with an unusually high event_count, especially when it is dramatically higher than the other entries, is a strong suspect for generating the erroneous wake events.

The output contains several columns, including the wakeup-source name and its event count. In practice, you are looking for a pattern like this:

name                 active_count  event_count  ...
---------------------------------------------------
device_a              0             0
possible_wake_source  0            47
another_device        0             1

The exact columns and values depend on the kernel, but the basic diagnostic idea is to find the source accumulating the most wake events. The highest event count is not absolute proof that the device is the culprit, but it is usually the first source worth testing when the system is immediately waking from suspend.

On a Yoga 9i, you may see an ELAN device associated with the touchpad. An example is:

i2c-ELAN06FA:00

The exact identifier is hardware-dependent. Do not copy ELAN06FA:00 blindly if your machine reports a different device name.

You may also find an Intel Integrated Sensor Hub (ISH) related device or another platform component. If one of those sources has the unusually high event count, investigate it instead of assuming the touchpad is responsible.

Test the source with the highest wake-event count

Once you have identified the wakeup source with the highest or otherwise suspicious event_count, temporarily disable its ability to wake the system and test suspend again.

For an ELAN device such as i2c-ELAN06FA:00, the test is:

echo "disabled" | sudo tee /sys/bus/i2c/devices/i2c-ELAN06FA:00/power/wakeup

Then suspend again:

systemctl suspend

Wait without touching the laptop.

If the laptop now remains suspended, the disabled device is a strong candidate for the erroneous wake event. If it still wakes immediately, re-enable that device and move to the next suspicious source.

This gives you a simple diagnostic loop: find the source with the highest wake-event count, temporarily disable it, and see whether suspend starts working.

Possible wake sources

The ELAN touchpad is only one possible source of erroneous wake events. Other hardware can behave similarly depending on the system’s firmware and Linux kernel.

Potential sources include:

• ELAN or other touchpad controllers
• Intel Integrated Sensor Hub (ISH)
• I2C devices
• USB devices and USB controllers
• GPIO-related devices
• ACPI or platform devices
• Other input or sensor hardware

On modern Intel laptops, the ISH is particularly worth checking because it connects to platform sensors and other hardware involved in system management. However, it should be treated as another candidate rather than automatically identified as the cause.

A useful troubleshooting process is:

flowchart TD
    A[System immediately wakes from suspend] --> B[Read wakeup_sources]
    B --> C[Find source with unusually high event_count]
    C --> D[Temporarily disable that source]
    D --> E[Test suspend again]
    E -->|Still wakes| F[Re-enable source and test next candidate]
    E -->|Stays suspended| G[Source is likely responsible]
    F --> B

If you have access to multiple Yoga 9i Aura or Core Ultra 200V/258V systems, comparing their wakeup-source output can also be useful. A source with an unusually high event count on the failing machine but not on a working machine is particularly interesting.

Re-enable a device after testing

The power/wakeup setting is runtime state. If you disabled a device for testing and want to restore its wake capability, use:

echo "enabled" | sudo tee /sys/bus/i2c/devices/i2c-ELAN06FA:00/power/wakeup

Replace the device path with the actual device you tested.

Re-enable failed candidates before moving on to another device unless you have confirmed that the device is responsible for the suspend failure.

Make a confirmed workaround persistent with systemd

If disabling a particular device reliably fixes suspend, you can apply the workaround during every boot with a systemd service.

For a confirmed ELAN wake-source problem, create:

sudo nano /etc/systemd/system/disable-elan-wakeup.service

Add:

[Unit]
Description=Disable wakeup for ELAN touchpad
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo "disabled" > /sys/bus/i2c/devices/i2c-ELAN06FA:00/power/wakeup'
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

Then enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable disable-elan-wakeup.service
sudo systemctl start disable-elan-wakeup.service

This service is specifically an example for an ELAN device. If your investigation identifies an ISH-related device or another wake source, create the service around the actual device path you confirmed instead of copying the ELAN path.

Verify device paths before making changes persistent

A hard-coded path such as:

/sys/bus/i2c/devices/i2c-ELAN06FA:00/power/wakeup

may not exist on every machine. Device identifiers can differ between models, firmware revisions, and hardware configurations.

Before making a workaround persistent, verify the path on the affected system:

ls /sys/bus/i2c/devices/

Then inspect the candidate device’s power-management directory:

ls /sys/bus/i2c/devices/i2c-ELAN06FA:00/power/

If the device is absent, do not create a service that repeatedly writes to a nonexistent path.

Compare kernel and firmware behavior

If two otherwise similar systems behave differently, compare more than just the device names.

Useful information includes:

uname -a

and:

sudo dmidecode -t system -t bios

You can also compare the wakeup-source output between a working and failing machine:

sudo cat /sys/kernel/debug/wakeup_sources

This can help determine whether the issue follows a particular device, kernel version, firmware revision, or machine configuration.

If the highest-count source does not fix the problem

The event count is a strong diagnostic clue, not a guarantee. A source can have wake events for legitimate reasons, and another device may still be responsible for the immediate resume.

If disabling the source with the highest event_count does not fix the problem, re-enable it and test the next highest or otherwise suspicious source. Continue through the candidates rather than assuming the first result was definitive.

If no candidate changes the behavior, investigate other causes such as kernel suspend regressions, firmware issues, ACPI problems, or user-space software interfering with suspend.

Do not disable every wake source

It can be tempting to disable the touchpad, ISH, USB controllers, and other devices until suspend works. That makes the diagnosis less useful and can break legitimate wake behavior.

For example, disabling an entire class of devices may interfere with:

• wake from keyboard or mouse
• sensor functionality
• tablet-mode detection
• touchscreen behavior
• device power management
• other platform features

A targeted workaround is preferable to globally disabling wakeup support.

Why this can apply beyond the Yoga 9i

The Yoga 9i 2-in-1 Aura Edition is a useful reference system because it combines modern Intel Core Ultra 200V hardware with a touchpad, sensors, and other platform devices that participate in Linux power management.

The exact problem is not necessarily specific to the Yoga 9i. Systems using the Core Ultra 7 258V can have similar classes of devices and power-management interactions, but the actual firmware, ACPI tables, I2C topology, ISH configuration, and kernel behavior determine which device can generate a wake event.

The transferable part of this guide is therefore the diagnostic procedure:

1. Reproduce the immediate wake.
2. Inspect /sys/kernel/debug/wakeup_sources.
3. Look for the source with an unusually high event_count.
4. Temporarily disable that source’s wake capability.
5. Test suspend again.
6. Re-enable it if the problem persists.
7. Move to the next suspicious source if necessary.
8. Only then make the confirmed workaround persistent.

Summary

Immediate resume from suspend on the Lenovo Yoga 9i 2-in-1 Aura can be caused by an erroneous wake event from a hardware device. The wake source could be an ELAN touchpad, the Intel ISH, or another device involved in power management.

A useful first clue is the event_count in /sys/kernel/debug/wakeup_sources. The source with the highest or unusually high wake-event count is often the first device worth testing. It is not definitive proof, so the result should be confirmed by temporarily disabling that source and testing suspend again.

Although the examples use the Yoga 9i Aura and an ELAN touchpad, the same diagnostic method can be applied to other laptops, including systems built around Intel Core Ultra 200V-series processors such as the 258V.