Waking immediately from suspend or hibernate. How I 'fixed' it, for me

Framework Laptop 13 Linux
1

Over the last few months I’ve had issues putting my Framework into Suspend or Hibernate.

Before I realized what was happening I would return to a completely drained battery.

I did manage to determine roughly what was causing the instant wake-up signals. I haven’t solved it, but I’ve stopped the problem. Jump to the end if you want the punch line.

I’m going to document how I troubleshooted and found out what was going on. Hopefully this helps someone else. My background here is that this is my first Linux device in a long while.

My system details:

Framework Batch: #4 (Oct 2021)
Framework Firmware: Latest one IIRC.
Framework CPU: 11th Gen Intel(R) Core™ i7-1165G7 @ 2.80GHz
Framework RAM: 16GB
OS: Manjaro Linux 21.3.1
Kernel: 5.19rc3-1 (currently)
Secure boot is turned off.
No other OS installed.

The Problem:

After putting the system into Suspend (S3) or Hibernate (S4) sleep states, the computer will resume within seconds.

Observable details:

The power button changes from solid on to slow pulsing as the system beings to sleep. After a second (longer if it’s trying to Hibernate) it will turn solid back on as the wake-up process begins.

Info Gathering:

  • tail/follow the systemd journal, while generating my own “start/stop” log entries:

journalctl -f in one terminal session, and echo 'SUSPENDING NOW' | systemd-cat -p warning && systemctl suspend -i in another to trigger a suspend and a log entry. One I’m logged back in I trigger another log event: echo 'awake' | systemd-cat -p warning

Here’s a sample log of what was happening to me.

First Troubleshooting Ideas

  • remove all framework expansion ports
  • have no additional input devices plugged in
  • turn off bluetooth (`systemctl disable --now bluetooth.service)
  • turn off networking (systemctl disable --now NetworkManager.service)
  • turn off xfce4-power-manager (xfce4-power-manager -q)
  • try different kernels:
    • 5.15.49-1 (LTS version, listed as recommended)
    • 5.16.20-2 (started here. It is now listed as Unsupported)
    • 5.17.15-1
    • 5.18.6-1
    • 5.19rc3-1 (experimental)

With these services turned off and with these kernels active, there was no difference for me nor produced any changes in the journal that I could detect (not exhaustive inspection).

Second Round of Troubleshooting Ideas:

  • try to learn about APCI and follow the Archlinux article on wakeup triggers.
  1. /proc/acpi/wakeup contents: cat /proc/acpi/wakeup (only showing the enabled devices here. There are so, so many disabled entries…)
Device S-state Status Sysfs node
PEG0 S4 *enabled pci:0000:00:06.0
XHCI S4 *enabled pci:0000:00:14.0
RP10 S4 *enabled pci:0000:00:1d.0
TXHC S4 *enabled pci:0000:00:0d.0
TDM0 S4 *enabled pci:0000:00:0d.2
TDM1 S4 *enabled pci:0000:00:0d.3
TRP0 S4 *enabled pci:0000:00:07.0
TRP1 S4 *enabled pci:0000:00:07.1
TRP2 S4 *enabled pci:0000:00:07.2
TRP3 S4 *enabled pci:0000:00:07.3
PWRB S4 *enabled platform:PNP0C0C:00
  1. use lspci to look up the Sysfs node pci values to figure out what each of the above entries means, while comparing the 4 character code to an incomplete reference guide (that I can’t find anymore).

Example: lspci | grep 00:14.0 OR lspci | grep USB

00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01)
00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 (rev 01)
00:0d.3 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #1 (rev 01)
00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20)
  1. Discover that powertop is a thing and use that. Checking the WakeUp Section shows:
>> Disabled      Wake-on-lan status for device wlp170s0                                                                 
   Enabled       Wake status for USB device usb3
   Disabled      Wake status for USB device usb1
   Enabled       Wake status for USB device 3-9
   Disabled      Wake status for USB device usb4
   Disabled      Wake status for USB device 3-10
   Disabled      Wake status for USB device usb2

Solution, for now:

Disabling USB device usb3 and USB device 3-9 via powertop or via the echo 'disabled' > '/sys/bus/usb/devices/<device_name>/power/wakeup'; command

This lets my laptop suspend and hibernate without issue.
I can turn on bluetooth, networking and the xfce4-power-manager back on without issue.

What are those devices?

Well, apparently at least the built in keyboard and trackpad. Though I don’t know for sure what else.

So to wake from suspend/hibernate, the lid needs to be opened or the power button needs to be short pressed. But this is better than the alternative.

If anyone knows how I can narrow down why those usb devices are acting up, or tips on understanding this area of Linux, that would be rad.

2 Likes
3

Press a key on the keyboard, or touch the trackpad?

5

For hibernate the computer is completely powered down. Pushing anything but the power button should not power on the system anyway.

1 Like
6

Not always the case.

Suspend can be triggered by inactivity, say 1hr, or by command / power menu (user triggered via software), or (and you know this already) lid close (user trigged by hardware).

A “lid already closed” state is not the only state the laptop can be in when sleeping / suspended.

This particular use case applies to all desktops AND laptops. All systems should be able to wake up by:

  1. Keyboard input.
  2. Mouse input / trackpad input / pointing device input.
  3. Power button trigger.

That’s the bare minimum wake triggers, by default. With that, the user ‘then’ should be able to decide which of the three they want to enable / disable.

The laptop form factor, then provides two additional wake triggers:

  1. Lid open.
  2. Pen / touchscreen input.

Additionally, there’s also wake from LAN / wifi, wake by proximity.

2 Likes
7

In recent years, power-on by lid open has been a feature on some laptop devices. This was also requested in one of the feature request threads here on the forum (one that Framework responded to as well). Let me see if I can find that post.

Hahaa…it’s from you:
Open Lid power on Action - Framework Laptop - Framework Community

If we are talking about specifically the Framework laptop, there’s the “Power on AC attach” BIOS option…so it’s not really / truly 'completely" powered off.

e.g. Without enabling WOL / WOWL, this power on AC attach does come in handy when a USB-PD adapter is linked to a remotely controlled smart switch (I don’t mean networking smart switch), for example.

8

This particular use case applies typically to business laptops (at least), especially those designed with a docking station where the laptop is closed, but with external peripheral…where the dock and the docked laptop is tucked away in the corner of a desk.

“Power on by keyboard” (BIOS menu of / from other systems)

image

1 Like
9

Thank you, Second_Coming that was well said and better than I could have done.

10

No problem at all. Got some time to kill today… so I thought I’ll put it to good use (better than how my day initially started).

1 Like
11

Just to be clear: Despite what other business laptops do (Thinkpads, for example) the Framework laptop will not wake from anything other than the power button when it is shutdown or hibernated.

This is by design.

2 Likes
12

Just to be clear:
The Framework laptop can wake from the power button and / or the by [Power on AC Attach]( BIOS guide - Framework Laptop - Framework Community) when it is shutdown or hibernated…by design.

2 Likes
13

Good catch!

However note, that by default this option is disabled.

1 Like
14

Agree.

[20 chars padding]

15

in case it helps anybody, a series of piped commands to cross reference enabled wake devices with your pci devices

cat /proc/acpi/wakeup | tail -n +2 | grep 'enabled' | awk '{print $4}' | grep -oE '.{2}:.{4}$' | xargs -I {} bash -c 'lspci | grep "{}"'
1 Like