Resumes immediately after suspend: How to diagnose

Help
4

Since the title is rather generic, I imagine someone will eventually arrive here not with a specific firmware bug but trying to find out how to do everything that led up to identifying the firmware issue.

Firstly, check if nixos-hardware has a module for your laptop/motherboard. If it does, it likely already has a fix (it has a suggestion even for you @mirrorwitch, though your other comment suggests that that is a copy/paste mistake from whoever copied the t14 config over).

If there is no module, or it doesn’t fix it, you’ll have to dig a bit further. Usually this works:

So, to diagnose this issue in general, you’ll want to read that file. It’ll give output like this:

Device  S-state   Status   Sysfs node
GP12      S4    *enabled   pci:0000:00:07.1
GP13      S4    *enabled   pci:0000:00:08.1
XHC0      S4    *enabled   pci:0000:09:00.3
GP30      S4    *disabled
GP31      S4    *disabled
PS2K      S3    *disabled
GPP0      S4    *disabled  pci:0000:00:01.1
GPP8      S4    *disabled  pci:0000:00:03.1
PTXH      S4    *enabled   pci:0000:02:00.0
PT20      S4    *disabled
PT21      S4    *disabled
PT22      S4    *disabled
PT23      S4    *disabled
PT24      S4    *enabled   pci:0000:03:04.0
PT26      S4    *disabled
PT27      S4    *disabled
PT28      S4    *enabled   pci:0000:03:08.0
PT29      S4    *enabled   pci:0000:03:09.0

This specifies which devices may wake up your system. They can be disabled using (substituting <DEVICE> with the name of the device from the first column):

echo <DEVICE> | sudo tee /proc/acpi/wakeup

Try that in sequence until you hit the device that causes the system to immediately wake up, and then add a udev rule to disable wakeups from that device:

  services.udev.extraRules = concatStringsSep ", " [
    ''ACTION=="add"''

    # See below on how to get the correct values for these three
    ''SUBSYSTEM=="pci"''
    ''ATTR{vendor}=="0x1022"'' 
    ''ATTR{device}=="0x1483"''

    ''ATTR{power/wakeup}="disabled"''
  ];

udev identifies devices by attributes. To get device attributes for a device from /proc/acpi/wakeup, take note of the sysfs node. If it’s a pci device, you can pretty easily get a list of all its attributes by using:

udevadm info -a /sys/bus/pci/devices/<numbers+colons after "pci:">

That’ll look something like this:

  looking at device '/devices/pci0000:00/0000:00:01.1':
    KERNEL=="0000:00:01.1"
    SUBSYSTEM=="pci"
    DRIVER=="pcieport"
    ATTR{ari_enabled}=="0"
    ATTR{broken_parity_status}=="0"
    ATTR{class}=="0x060400"
    ATTR{consistent_dma_mask_bits}=="32"
    ATTR{device}=="0x1483"
    ATTR{vendor}=="0x1022"

Any of those attributes can in theory be used for identification (and they’re useful for writing more complex rules), but in this case device and vendor is probably what you want.

If that still doesn’t help, there’s no clear formula. It’ll take sleuthing like what @mirrorwitch did, and likely means some kind of firmware issue is causing the problem.

6 Likes